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ABSTRACT 


Although there is a Configuration Management (CM) policy in place at the 
Naval Air Warfare Center Training Systems Division (NAWCTSD), it has not 
been implemented in a manner that standardizes CM across all weapons platforms 
and programs. Furthermore, CM requirements are not interpreted the same by all 
personnel required to implement CM for systems acquisition or during the 
systems’ life-cycle support phase. NAWCTSD acquires and supports systems for 
Naval aviation, surface, and subsurface communities as well as other Government 
agencies. 

This thesis presents the essential elements of a comprehensive CM policy and 
an implementation strategy that addresses the diverse customer base and diverse 
elements of NAWCTSD required to implement CM policy. It presents research 
about other Government agencies that have successfully implemented CM. 
Technical treatises were researched and pertinent information presented. 
Government regulations and military standards were researched to determine which 
regulations apply to NAWCTSD and to resolve potential conflicts arising from the 
interpretation of regulations and military standards. The impact of current 
acquisition streamlining efforts is presented and analyzed. 
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I. INTRODUCTION 


A. BACKGROUND 

Although there is a CM policy in place at the Naval Air 
Warfare Center Training Systems Division (NAWCTSD), it has not 
been implemented in a manner that standardizes CM across all 
weapon platforms and programs. Furthermore, CM requirements 
are not interpreted the same by all personnel required to 
implement CM for systems acquisition or during the systems' 
life-cycle support phase. It is highly desirable to establish 
the minimum acceptable CM standards that all programs must 
meet. 

It is anticipated that implementation of an effective 
acquisition CM policy at NAWCTSD will provide a base for the 
development and implementation of an effective CM policy for 
the life-cycle of acquired systems. Although life-cycle CM 
will be discussed in this thesis, the main thrust will be the 
determination of an effective acquisition CM policy for 
NAWCTSD. 

The present CM policy at NAWCTSD is governed by 
NAVTRASYSCENINST 4130.3, dated 29 September 1993. It is 
presently under review for revision and will include 
information derived from this thesis as part of a planned 
revision scheduled to be performed annually. The instruction 
title will be changed to NAWCTSDINST 4130._M to reflect the 
new organizational title. NAWCTSD was previously the Naval 
Training Systems Center (NTSC). NTSC became NAWCTSD after the 
present NTSCINST 4130.3 was implemented. In this thesis the 
instruction will be referred to as the NAWCTSD 4130._M 
instruction to reflect the new correct name for the updated 
instruction. 

Competency 1.3.2, the Program Support Competency, is the 
lead organization for configuration management at NAWCTSD. It 
is responsible for establishing CM policy and for insuring 
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that consistent and acceptable CM is practiced in all programs 
under the cognizance of NAWCTSD. Competency 3.0 is updating 
and modifying the NAWCTSD CM instruction as an assist task to 
Competency 1.3.2. The NAWCTSD instruction is a derivative of 
the NAVAIRINST 4130.1C dated 31 January 1992. The 
implementation of NAWCTSDINST 4130._M will encompass overall 
CM policy and promulgate instructions and other directives and 
guides to all competencies required to implement CM policy. 

Competencies 1.3.2 and 3.0 are not the only competencies 
with an interest in CM policy at NAWCTSD. Several other 
competencies are responsible for implementing CM policy either 
in conjunction with an acquisition (for new systems or 
upgrades to existing systems) or in conjunction with ongoing 
Life-Cycle Support (LCS). Outlying field activities, called 
In-service Engineering Offices (ISEOs), provide trainer system 
engineering support (modification) for hardware, software, and 
technical documentation as well as a variety of other trainer 
and training system support functions. 

Competency 4.0, the Engineering Competency, and the ISEOs 
are responsible for acquisition support of training systems as 
well as hardware, software, and documentation status. They 
are also responsible for implementation of automated or other 
CM and Configuration Status Accounting (CSA) functions and 
systems in support of systems acquisitions efforts and their 
fielded systems. 

Competency 3.0, the Logistics Competency, performs many 
support functions including support for systems acquisition 
efforts and is intimately involved in ongoing CM issues 
concerning "fielded" systems. "Fielded" in this context, 
implies that the system is no longer under the direct 
cognizance of one of the acquisition Project Managers (PJMs) 
as an acquisition oriented project. PJMs retain cognizance 
over the system for the life of the system, but the emphasis 
for system support changes from acquisition to LCS when the 
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system is fielded. Within Competency 3.0, the Integrated 
Logistics Support Manager (ILSM), one of the Competency 1.0.X 
competency managers, will determine general CM requirements, 
CM data requirements, and CM audit requirements in 
consultation with the Project Manager (PJM). 

NAWCTSD procures and supports systems which provide 
unique CM challenges. Most of the acquired and supported 
systems are complex state-of-the-art systems and are acquired 
in small numbers. Maintenance support is provided almost 
exclusively by contractors. Technical documentation accuracy 
and system concurrency with weapon systems or other platforms 
is crucial and will cover a span of many years dependent upon 
the weapon system. CM plays a major role in assuring that 
system changes are properly documented, that hardware and 
software changes are traceable to requirements, and that 
baselines are accurately represented in data management 
systems. Simply put, all documentation for both hardware and 
software must accurately reflect the current system 
configuration. 

Systems acquired and supported by NAWCTSD are widely 
dispersed throughout the continental United States, Hawaii, 
Alaska, and in many foreign countries. Additionally, NAWCTSD 
serves many customers such as the surface, sub-surface, and 
aviation communities within the Navy as well as the Army, Air 
Force, Marines, and other Federal agencies. 

A memorandum released by the Secretary of Defense, 
William Perry [Ref. 1] , states that unless waivered, military 
specifications and standards will not be applied to the 
acquisition of new weapon systems. This has introduced an 
element of question in the implementation of CM based on MIL- 
STD-973 and other standards. If military standards are not to 
be used in the development of new systems, then the 
implementation of CM in a standardized fashion using MIL-STD- 
973, may not be a goal of NAWCTSD as a matter of policy. 
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It may be that NAWCTSD will rely on industry standards 
defined in individual contract definitions to implement CM. 
This question will be more thoroughly discussed in Chapter V, 
Analysis and Interpretation of Data. 

B. RESEARCH AND SUBSIDIARY QUESTIONS 

This thesis will address the following research question: 

What should be the essential elements of a configuration 
management (CM) policy for NAWCTSD acquisitions and how 
might this policy be implemented? 

The following subsidiary questions will further define 
the problem and lead to a more complete analysis: 

What are the essential elements of CM policy and what are 
the requirements established by DoN, DoD, and other 
Federal Government regulations? 

What are the basic components of CM policies that exist 
for similar Government organizations and industry firms? 

What are the significant problems and issues associated 
with establishing a CM policy that is unique to NAWCTSD 
and how might these problems and issues be resolved? 

These subsidiary questions will be further subdivided into 
sub-subsidiary questions as necessary to completely answer 
each element identified. This approach to problem solving, 
known as the dendritic approach [Ref. 2, p. 14-6], is 
diagrammed in Appendix A. The reader is invited to refer to 
Appendix A as needed to gain a picture of the complete problem 
description and proposed solution. 
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C. PROBLEM DEFINITION 

The major problem is that CM is neither uniformly nor 
effectively applied in the acquisition and life-cycle support 
of training devices and equipment procured or accepted for 
support after procurement by NAWCTSD. The magnitude of this 
problem is reflected in the size of the inventory supported by 
NAWCTSD, which is approximately 2,500 trainers and training 
systems valued at approximately $3.5B located at 289 
individual fleet and training units. 

In an era of continuous downsizing of the armed forces, 
it is crucial that simulation systems and trainers be properly 
maintained and that the configuration of those systems 
accurately reflect the systems they support. CM, properly 
executed, can save potentially billions of Operation and 
Maintenance (O&M) dollars by improving system software and 
hardware maintenance and by reducing the need for operational 
equipment and personnel required to be used in training 
scenarios. 

In some cases, an adequate CM system has not been 
established during acquisition. This can be problematic 
during the acquisition phase and may carry over into the 
operational system for its entire life-cycle. It is important 
that the process of CM be started early in the acquisition 
phase in order to assure that system baselines are accurate 
and fully documented at the time the system is accepted by 
NAWCTSD and the user. Such a CM system should be in place and 
workable prior to acceptance of the system by the Government. 

The level (system, sub-system, sub-sub-system...), 
methodology (automated, manual, combination of both), and 
systems (training devices, technical documentation) on which 
CM is to be performed is not as clearly defined in existing 
instructions and guidelines as some personnel would prefer. 

Competency 1.3.2 is responsible for overall CM policy 
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(writing instructions, defining scope, defining methodology, 
etc.). Other competencies within NAWCTSD are responsible for 
implementing that policy. It is not clear, therefore, what 
role each of the implementing competencies, including 
acquisition competencies, will play in establishing or 
actually performing CM on systems and technical documentation. 
Nor is it clear what the needs of each of those competencies 
are with respect to CM. The role of contractors and their 
performance of CM during the system's operational phase should 
also be clearly defined. 

These problems, in the aggregate, have prevented the 
effective implementation of CM across the broad spectrum of 
NAWCTSD supported and acquired devices. It is evident that CM 
is being performed, but the evidence indicates that it is 
spotty, that there is no unified data management regarding 
reporting systems, that different competencies interpret the 
level to which CM is to be performed differently. This may be 
caused by the diverse customer base and because NAWCTSD is 
managing many unique and totally different configuration 
items. These problems result in inefficiencies in the overall 
system. 

It should be noted that differences in the method of 
performing CM and the level to which it is to be performed may 
differ between training systems and their respective 
communities. The core CM effort at NAWCTSD needs to be 
standardized and a standard approach to accomplishing CM 
across all supported communities and devices should be 
established. In this context "core" means CM procedures and 
methods used by NAWCTSD in support of oversight CM functions 
that support all Cognizance 2"0" systems. An example of this 
would be the functions of the NAWCTSD Trainer Engineering 
Change Control Board (TECCB) and the central status accounting 
system used to document multiple configuration items which 
span all systems supported by NAWCTSD. 
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It is evident that different competencies perform the 
functions of CM differently. Different CM systems are being 
used (and this will likely continue to be the case for the 
reasons stated in the previous paragraph). Some of the 
different types of physical systems include fully automated 
(mainframe, mini-computer, or PC) , semi-automated, semi-manual 
depending upon the emphasis, manual, or partially implemented 
systems that simply document the system or item according to 
device number, nomenclature, and serial number (essentially no 
more than inventory maintenance). There are also different 
technical approaches to CM based on the individual program or 
system. It is not the difference in systems that is 
important, it is the difference in the methodology, level, and 
types of reporting and documentation that must be studied and, 
if necessary, changed to improve the overall accomplishment of 
NAWCTSD core CM in a standardized fashion and of approaching 
development of CM systems in support of different platforms, 
weapon systems, and communities served by NAWCTSD. 

Records which document baselines and configurations, 
whether digital or hard copy, are not standardized, are 
difficult to understand across all platforms, and do not share 
common data elements. Traceability from requirements to 
system configuration (including the configuration that results 
after modification to the system) is, in some cases, spotty or 
non-existent and is not in a standardized format. Digital 
information cannot be shared universally. 

A standardized approach to CM will make reporting simpler 
and will facilitate better communications across Service or 
agency borders. CM, if not properly performed may result in 
situations where a weapon platform may not be accurately 
modeled by the simulation system. In those cases training can 
have a detrimental effect. The problem is mitigated if system 
users know the exact configuration of the system so that 
system differences can be identified in the training scenario. 
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Differences may be such that the system is degraded over that 
being used in the fleet. In some cases systems may be 
upgraded prior to fleet release of the upgrade or 
modification. Whichever the case, it is imperative that the 
exact system configuration be known to the users of the 
system. 

D. SCOPE 

The main thrust of this thesis will be to determine the 
essential elements of a CM policy for NAWCTSD and to provide 
recommendations for implementing a CM policy at NAWCTSD. The 
thesis will include a study of at least one example of 
effective (successful) CM policy implementation at at least 
one Government organization and one industry firm. 

E. LIMITATIONS 

This thesis will not include a recommended method of 
internal NAWCTSD review for the recommended CM policy at 
NAWCTSD. The thesis will not include details of 
implementation for any specific program or acquisition being 
supported or conducted at NAWCTSD nor will it consider 
implementation with respect to any individual branch or other 
organizational unit having CM responsibilities unique to a 
specific program. Rather, the recommended policy will include 
the essential elements of a comprehensive CM policy 
implementation with a view to the overall policy of NAWCTSD 
and its CM requirements with respect to existing Government 
regulations. Recommendations concerning organizational 
elements and individual responsibilities for overall CM 
implementation will be included. 

This thesis will not attempt to explain the technical 
details of CM as practiced. Rather, it will concentrate on 
overall CM policy elements and implementation. Technical 
explanations concerning automated or manual CM systems will be 
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only generally discussed ■ or referenced. Technical 
explanations will be kept to an absolute minimum in order to 
facilitate easy reading by an audience which may not be 
familiar with the technical aspects of CM. 

F. ASSUMPTIONS 

It is assumed that the reader is generally familiar with 
the concepts of CM as practiced in both Government and 
civilian organizations. It is assumed that the reader has 
ready access to Government instructions, written policy, 
supplemental written material, and other references listed in 
the list of references. It is also assumed that the reader 
has sufficient technical background to independently analyze 
technical material presented but not explained in the body of 
the text as it refers to CM issues such as that covering the 
acquisition of software and hardware. 

G. LITERATURE REVIEW AND METHODOLOGY 

There is a large body of current literature from which to 
conduct research concerning CM theory. This thesis is not so 
concerned with CM theory as it is with the successful 
implementation of CM policy at NAWCTSD. Therefore, the 
literature searched will be to synthesize information gleaned 
from an agglomeration of general information concerning CM 
policy and specific information concerning the successful 
implementation of CM policy at one comparable Government 
entity and at one comparable industrial organization. The 
methodology employed involves data searches at the NPS 
library, research of Government regulations and instructions 
including NAWCTSD and NAVAIR instructions and implementing 
guidelines and instructions from other Government agencies and 
industrial firms. Additionally, Government representatives 
from various agencies and from civilian institutions will be 
interviewed to determine how CM policy was initiated at their 


9 




respective organizations or in their acquisition programs and 
the success of the CM policy implemented. 

H. DEFINITIONS AND ACRONYMS 

Appendix B provides a Glossary of Acronyms used in this 
thesis. See Appendix C for definitions of terms. These 
definitions were derived from NAWCTSDINST 4130._M, Appendix A, 
NAVAIRINST 4130.1C, Appendix A, and DoD Instruction 5000.2. 

I. ORGANIZATION OF STUDY 

The seven chapters of this thesis are organized in such 
a manner that they present a logical progression from problem 
statement to conclusions and recommendations. The inclusion 
of Appendix A, a dendritic analysis, is key to the development 
of a satisfactory conclusion and recommendations describing 
the essential elements of a NAWCTSD Configuration Management 
Policy. It is key because it represents the whole of the 
problem in a graphical format that is easy to understand. The 
organization of the thesis complements the organization of the 
problem as presented in Appendix A and facilitates development 
of matrices which cross reference answers to questions and 
data. 
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II. LITERATURE REVIEW AND THEORETICAL FRAMEWORK 
A. STRUCTURAL FRAMEWORK 

The structural framework for this thesis is based on a 
study of successful implementation of CM policy at a 
Government and industry organization as well as a 
comprehensive search of current DoD, DoN, and other Government 
instructions, specifications, and standards. Personnel from 
other Government agencies and from industry firms which have 
successfully implemented CM under a CM policy were interviewed 
and provided a rich resource of information concerning the 
essential elements of a CM policy and current theoretical 
knowledge of CM. During the period this thesis was being 
written, the Perry Memo [Ref. 1] began to have a significant 
effect on the implementation of CM policy within the 
acquisition community. As much as possible, research 
conducted, and the structural framework of this thesis, 
includes up-to-date policy that encompassed changes made to 
accommodate the paradigm shift in acquisition policy mandated 
by the Perry Memo [Ref. 1]. 

The National Aeronautics and Space Administration (NASA) 
was selected as a comparable Government organization to study 
for its CM policy on the Shuttle program. The Shuttle program 
represents a large and complex system under effective hardware 
and software configuration management and control. This 
thesis will study information derived from NASA's software and 
hardware CM policy (See Appendix D) as it relates to 
development of the complex shuttle hardware and software 
development, modification, and life cycle support. 

Loral Corporation, the Shuttle software development 
contractor, was chosen as a comparable industry organization 
for study of its CM policy. Loral, Incorporated was a good 
choice for an industry firm because part of the Loral success 
story in CM is a result of the CM policy in place at the NASA. 


11 



The implementation of a successful CM policy at Loral (Loral's 
own policy, not the NASA CM policy) for software work done on 
the Shuttle system under contract to NASA serves as a good 
industry model for design of similar CM policy implementations 
in other organizations, including Government organizations. 

Loral was chosen because it represents a highly 
successful software development company involved in a highly 
successful, very complex, software development effort 
supporting the shuttle. The shuttle software development 
process, at Loral in Houston TX, was rated at a Level Five 
Software Process Capability Maturity [Ref. 3], the highest 
level achievable, after a process assessment conducted with 
the assistance of the Software Engineering Institute [Ref. 4, 
p. 81, par. 1.4.1], 

This thesis is being written with an emphasis on DoD CM 
policy and issues; therefore, the U.S. Army's ATACMS-BAT 
program was studied and will be referenced as an additional 
comparable Government organization with a proven, successful, 
CM policy. 

Research done on CM policy will address both acquisition 
and life-cycle issues as part of the structural framework. 
Theoretically, effective implementation of CM for the life 
cycle begins early in the acquisition phases. 

Other areas of research in the structural framework that 
are applicable to solving the problem of developing and 
implementing a successful CM policy at NAWCTSD are contained 
in numerous management and organizational treatises and in 
DoD, DoN and other Government instructions and specifications. 
These were studied to determine what is required statutorily 
and what is simply recommended They were also analyzed to 
determine the hierarchical nature of the instructions and 
specifications governing CM policy, the recommended managerial 
policy from a "best practices" perspective, and the technical 
requirements of a CM policy. 
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Another part of the structural framework is in the area 
of standardization and program integration across a wide 
variety of platforms serving multiple customers. Policy was 
studied to determine if a competency aligned organization, 
such as NAWCTSD, can successfully integrate efforts and 
standardize on procedures effectively based on existing 
Government policy. Standardization of the CM process itself 
is studied to determine the extent to which CM policy should 
strive to standardize processes and policy. 

Attention is also given to the involvement of upper 
management in the success of CM policy implementation. 

B. KEY FACTORS AFFECTING IMPLEMENTATION OF CM 

Following are the key factors affecting implementation of 
an effective CM policy at NAWCTSD: 

1. Determination of the essential elements of CM to be 
performed by NAWCTSD for the entire life cycle of each type of 
system under its cognizance. Those systems represent the full 
spectrum of training devices from simple electro-mechanical 
systems to complex simulators such as the F/A-18 Flight 
Simulator. In some cases there are a large number of trainers 
comprising a system, such as at a Navy "A" school. In other 
cases there may be only one or two or up to ten simulators to 
support a system such as the F/A-18 Flight Simulators. 

2. Determination and agreement of the principal 
elements of CM across a wide spectrum of disciplines and 
across a diverse number of organizational competencies at 
NAWCTSD. 

3. Integration of the efforts of individuals within the 
organizational competencies at NAWCTSD. 

4. Written interpretation of a specific set of rules, 
directives, and regulations concerning implementation of CM 
within the Government that pertain to NAWCTSD. 
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C. CAUSAL RELATIONSHIPS 


There are a number of causal relationships that exist 
among the key factors that impact on the effectiveness of CM 
policy implementation at NAWCTSD. One significant 
relationship is the impact that the organizational structure 
of NAWCTSD imposes on the requirement that CM be implemented 
in a "standardized" fashion. Customers of NAWCTSD comprise 
elements of the surface, sub-surface, aviation, and 
intelligence communities within the Navy. NAWCTSD also 
acquires training systems and provides LCS for those training 
systems for the Marine Corps, the Air Force, the Coast Guard, 
and other Federal agencies. Support for Cog 2"0" systems is 
shared over several competencies within NAWCTSD such as 
Project Direction/Management, Contracting, Engineering, and 
Logistics. The efforts of these and other individual 
competencies must be integrated over the life of the systems 
in order to assure effective and efficient CM. Therefore, 
there is a causal relationship concerning internal 
organizational responsibility and overall control of the CM 
processes and systems. Which internal organizations will 
determine CM policy and which internal organizations will 
implement that policy? How will the needs of multi-service 
customers be made known to those in charge of policy 
development? Each of these questions has a cause and effect 
centered around the overall organizational structure. These 
relationships are complicated by the diverse, multi-service, 
multi-agency customer base. 

There are causal relationships relating to Government 
instructions and directives on CM and the individual 
interpretations of the requirements for CM based on those 
instructions and directives. This problem is especially 
profound given the multi-service nature of the CM systems that 
must be implemented. CM concepts become mixed when viewed 
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from the perspective of a multi-service environment. 

D. CONTRIBUTIONS OF THIS THESIS TO THE GENERAL BODY OF 
KNOWLEDGE 

This thesis reviews the general body of knowledge 
concerning the essential elements of CM policy and 
implementation of CM policy for organizations acquiring and 
supporting complex, one-of-a-kind or few-of-a-kind systems. 
It also provides a road map for implementing CM in a multi¬ 
service environment and within the organizational framework of 
a competency aligned organization. 

It addresses CM implementation and effective 
standardization issues in a diverse organizational climate. 
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III. BACKGROUND OF CM ISSUES AT NAWCTSD 


A. BRIEF HISTORY OF CM AND CM POLICY AT NAWCTSD 

NAWCTSD is designated as an Office of Primary 
Responsibility (OPR) per NAVAIRINST 4130.1C. This designation 
carries with it certain responsibilities. Those 

responsibilities are to: 

(1) Provide CM of assigned configuration items 
throughout their life-cycle. 

(2) Prepare and maintain CM plans for assigned 
configuration items, obtaining approval of those plans, 
and assuring proper implementation of NAVAIRINST 4130.1C. 

(3) Manage and provide direction for the staffing of 
all engineering change proposals, related weapon system 
engineering change proposals, Trainer Engineering Change 
Proposals (TECPs), and requests for major and critical 
deviations and waivers from initiation until submittal to 
the Trainer Engineering Change Control Board (TECCB). 

(4) Implement TECCB directed actions. 

(5) Maintain the status of implementing actions for 
approved engineering changes, deviations, and waivers. 

(6) Conduct audits and establishing baselines. 

(7) Establish and maintain an adequate configuration 
status accounting system. 

NAWCTSD has complied with the requirements listed above 
by issuing instructions which implemented those requirements. 
NAWCTSDINST 4130._M is the latest instruction issued. Prior 
to the issuance of the NAWCTSDINST 4130._M there were a series 
of NTSCINST 4130.X implementing instructions. Each of those 
were issued in compliance with updated instructions from 
NAVAIR. To date, that sequence of instructions has been 
sufficient to provide a measure of success in accomplishing 
configuration management and control over the inventory of 
Cognizance Symbol 2"0" equipment. 

NAWCTSD, under several different names since it became 
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the Navy's premier training devices center in the mid 1940s, 
has supported its inventory of devices in an excellent manner. 
The necessity for formulating a more coherent CM policy is not 
because NAWCTSD has failed to accomplish its assigned 
responsibilities with regard to CM, but because it is 
necessary to upgrade its capabilities to conform to more 
stringent demands from customers both internal and external to 
NAWCTSD and from rapid changes in technology. 

NAWCTSD is faced today with the same problems of most 
industries. That is the problem of attempting to keep abreast 
of what could only be termed revolutionary changes in 
technology. Up until the early 1980s the major cost of 
training systems was in the hardware. In fact, hardware 
comprised the bulk of the system. Software was a lesser cost 
item though, even at the outset, managing software presented 
new and unique challenges especially with respect to 
configuration management and configuration status accounting. 
Today, the major cost of systems is in the development and 
maintenance of the software which comprises the bulk of the 
system's capabilities. 

This situation presents system developers with the 
problem of performing configuration management on both 
hardware and software and of integrating that effort. This 
has required immense change and flexibility in CM technology, 
methods, and processes. All systems developers are faced with 
these changes and are attempting to respond. 

NAWCTSD is currently in the process of updating and 
implementing CM instructions and policy because of the many 
changes that have and continue to take place in technology, 
methodology, and requirement for CM. Added to those changes, 
during the recent past there has been a revolutionary change 
in DoD acquisition policy. The recent memorandum on 
acquisition reform by the Secretary of Defense will likely 
result in additional changes in CM policy at NAWCTSD. 
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B. UNIQUENESS OF THE NAWCTSD CM EFFORT 

The uniqueness of the NAWCTSD CM effort cannot be 
overemphasized. As mentioned previously, NAWCTSD serves many 
customers. Although NAWCTSD is an integral part of the NAVAIR 
team and is functionally under the direction of NAVAIR, it is 
also an integral part of the surface and sub-surface Navy. 
For many years NAWCTSD, under different names, was 
functionally under the direction of several different Navy 
Systems Commands but still always provided services to the 
many different Navy commands on both coasts. They also 
provided and continue to provide services to the Marine Corps 
and other military Services and did so long before "jointness" 
was a buzzword. At this time, NAWCTSD is working closely with 
NASA under a Memorandum of Agreement (MOA) and has ties with 
other non-DoD agencies. This has made the problem of 
implementing CM in a standardized fashion immensely difficult. 

Within the Navy alone, the surface differs from the sub¬ 
surface Navy, both of which differ from the aviation part of 
the Navy on a number of issues concerning documentation, 
training, systems procurement, and life-cycle support. There 
are differences between Services and between non-DoD agencies 
in their requirements for documentation, training, systems 
procurement, and life-cycle support issues. 

Additionally, NAWCTSD may be tasked to provide life-cycle 
support, including CM, on a device procured by another agency 
and then inducted into the NAWCTSD inventory as a Cognizance 
2"0" device or system. 

In the aggregate, NAWCTSD is faced with a unique 
challenge in performing CM both during acquisition and after 
acceptance by the user agency simply because of the many 
differences in the wide variety of customers serviced by 
NAWCTSD. This challenge cannot be overlooked in the 
development and implementation of any over-arching policy, 
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such as a CM policy. 

Added to the difficulties of multiple and diverse 
customers, is the diversity in the products delivered by 
NAWCTSD. The product may consist of an immensely complex, 
one-of-a-kind or few-of-a-kind device. Or it may consist of 
a less complex device procured in larger numbers but widely 
distributed. It is the diversity of the types of devices and 
their distribution that adds greatly to the complexity of 
establishing effective CM over a given device. 

As an example of a complex, few-of-a-kind device, the 
F/A-18 trainer suite consists of number of weapon tactics 
trainers which are immensely complex and include a state-of- 
the-art visual system. The suite also includes a number of 
operational flight trainers, somewhat less complex than the 
weapon tactics trainers, but does still have a visual system. 
The last part of the suite consists of several part task 
trainers, which are the least complex but by no means simple 
systems. 

All of the systems in the trainer suite rely heavily on 
digital technology and are driven by huge sophisticated 
software routines. The systems are widely distributed 
throughout the United States and overseas in several 
locations. They were procured over a period of approximately 
ten years and thus represent a large disparity in technology 
from the first to the last system procured. Several of the 
weapon tactics trainers were procured by NAVAIR with an assist 
task from NAWCTSD but all are Cognizance Symbol 2"0" systems 
for support purposes. 

The F/A-18 aircraft has undergone evolutionary 
modifications since it was introduced into the fleet, and it 
continues to undergo upgrades and modifications to both 
software and hardware. All of these modifications have to be 
incorporated into the F/A-18 trainer suite, if applicable, and 
must be tracked for CM purposes both by the organizations 
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responsible for the aircraft baselines and by the 
organizations responsible for the trainer suite baselines. 

As can be seen from a description of the F/A-18 trainer 
suite, the problem of performing CM on that system is 
immensely challenging from a number of perspectives. It is a 
challenge because of the number of different versions of the 
system in existence. It is a challenge because NAVAIR 
procured some of the systems and NAWCTSD procured some. The 
systems are widely distributed geographically and this adds to 
the problem of effective configuration management and control 
since each system's baseline must-be completely and accurately 
documented. The requirements for changes to the systems must 
be tracked from aircraft changes as well as possible changes 
to the simulation systems due to evolutionary development or 
latent problems in either software or hardware. Even changes 
in training doctrine or tactics from the operational side of 
the house must be documented and tracked. 
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IV. METHODOLOGY 


A. RESEARCH DESIGN 

Research for this thesis will be conducted using Appendix 
A as a road map. The dendritic approach outlined in Appendix 
A provides a breakdown of the critical issue into sub¬ 
objectives which are further broken down into sub-sub¬ 
objectives as needed. 

The initial stages of the research involved a 
comprehensive analysis of the literature identified in the 
literature search as applicable. Proceeding from that 
analysis several of the subsidiary research questions were 
answered. As an example, the principal elements of CM policy 
and requirements established by the DoN, DoD, and other 
Federal Government regulations were clearly identified and 
catalogued according to their order of precedence. Which 
regulations, instructions, and directives apply to the NAWCTSD 
CM effort and which are subordinate or superior were 
identified. 

A review of the NASA, Loral, and ATACMS-BAT, CM policies 
was performed to clarify the direction taken by those 
organizations to determine their best CM policy. This 
approach to solving some of the subsidiary questions is 
appropriate simply because not all of the answers to 
determining the essential elements of CM are contained in DoD 
and DoN regulations. A study of similar organizations helped 
clarify which policy elements were critical, and, equally 
important, which ones worked best to successfully implement 
CM. 

One visit was made to NAWCTSD to discuss implementation 
policy with Competency 3.0. Competency 3.0 provided a draft 
of the proposed changes to the existing CM instruction, 
NAWCTSDINST 4130._M and clarifying remarks concerning the 
present status of CM implementation at NAWCTSD. No formal 
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questionnaires were developed or used at the initial meeting 
with Competency 3.0 personnel since the author is familiar 
with the problems and personnel and only required an update on 
the status of the new instruction being developed. 

Other NAWCTSD personnel were interviewed to get a flavor 
for the organizational problems involved in implementing an 
effective policy. Notes resulting from those interviews was 
used in the overall analysis of the data. No formal 
questionnaires were used. 

Personnel responsible for CM policy and implementation 
from NASA, Loral, and the ATACMS-BAT program office were 
interviewed over the telephone. Information concerning their 
policies was obtained. Pertinent information is contained in 
Appendices D, E, and F and was used to supplement information 
contained in referenced texts, instructions, and 
specifications. 

Several personnel who practiced CM at the grassroots 
level of the organizations involved in this study were 
interviewed. Thus, the author gained a working level 
perspective of the effectiveness of implementing CM policy. 

The information derived was used to enhance development 
of policy for NAWCTSD. 

B. ANALYTIC STRUCTURE 

Analysis of the data derived from the applicable 
literature and interviews was used to develop a data matrix 
which linked data sources to items to be studied. From that 
matrix, it was decided which subsidiary research questions 
could be completely and adequately answered from the 
literature, instructions, specifications, and technical 
documents available and which required a more heuristic 
approach by developing answers based on the study of other 
successful CM policies and the interviews conducted. Key to 
the successful completion of this thesis is contained in 
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Appendix A. Appendix A provides a sufficient breakdown of the 
critical issue, the research question, to assure a 
comprehensive answer to all of the subsidiary research 
questions. Questions asked during interviews and answers 
to those questions were analyzed and included in the matrix 
described in the preceding paragraph. Analysis of those 
questions and answers is expected to contribute significantly 
to the body of knowledge to be developed as a result of this 
study and to a more "practical" solution to the research 
question. 

The results of the analysis are the identification of the 
essential elements of a CM policy and recommendations 
necessary to implement a CM policy at NAWCTSD. Careful 
scrutiny of Appendix A assured that all relevant and important 
issues were addressed and questions answered. 
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V. PRESENTATION OF DATA 


A. INFORMATION DERIVED FROM LITERATURE SEARCH 

The following paragraphs present information derived from 
searching Government regulations, instructions, standards, and 
other pertinent literature concerning CM. The facts presented 
in this chapter will be analyzed in Chapter VI. All 
information is referenced to allow the reader easy access to 
source documentation for further study if desired. 

Only the information concerning CM policy or 
implementation of that policy is presented. Only the most 
important facts are presented in the interest of readability 
and brevity. Information is organized by several of the most 
useful sources. Each sub-section below provides information 
from the source listed in the sub-section title. Within sub¬ 
sections, additional references are provided as appropriate. 
A wealth of information was derived from the "Military Project 
Management Handbook," other sources of information in the 
remaining sections do not contain information that was a 
repeat of information contained in Section 1 covering the 
"Military Project Management Handbook." 

1. "Military Project Management Handbook" 

Sources of regulations concerning CM are found at both 
the Department of Defense (DoD) level and at the Service 
level. Following is a list of sources [Ref. 5, p. 8.2]: 

DoD Instruction 5000.2, Part 9, Sections A and B, "CM and 

Technical Data Management" 

DoD-STD-100, "Engineering Drawing Practices" 

DoD-STD-2167A, "Defense Systems Software Development" 

DoD-STD-2168, "Software Quality Assurance" 
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MIL-STD-48OB, "Configuration Control - Engineering 
Changes, Deviations, and Waivers" 

MIL-STD-973, "Configuration Management" 

MIL-HDBK-61, "Configuration Management" (aids in the 
implementation of Draft MIL-STD-973) 

IEEE Standard, 828-1983, "IEEE Standards for Software CM 
Plans" 

NASA Technical Memorandum 85908, "Software Control and 
System Configuration Management: A Systems-Wide 
Approach" 

The above sources are not inclusive of all sources referenced 
in this thesis; they are the sources listed in the Military 
Project Management Handbook. 

Configuration management is different from configuration 
control. (See Appendix C for definitions of each.) 
Configuration management is a set of processes which have 
specific product relationships. Configuration control is a 
generalized process. [Ref. 5, p. 8.3] 

DoD-STD-2167A is concerned with software development and 
therefore does not consider configuration management in a 
system-wide context as do many of the other sources used in 
the research phase of this thesis. However, many of the same 
principles apply to both hardware and software CM. This 
thesis will consider the facts derived from DOD-STD-2167A 
whenever those facts may be considered appropriate to the 
development of overall or system-wide CM policy. 

Configuration Management for both hardware and software 
begins at the time of contract award. The Government's 
configuration management plan should be developed early in the 
concept exploration and definition life-cycle phase, and 
should be updated at the beginning of each succeeding phase to 
reflect changing requirements. [Ref. 5, p. 8.4-5] The 
Government CM plan and the contractor's CM plan should, as a 
minimum, be coordinated. [Ref. 5, p. 8.5] The contractor CM 
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plan should have separate sections detailing the contractor's 
process and procedures for configuration identification, 
conf iguration control, status accounting, subcontractor/vendor 
control, configuration audits, and life-cycle phasing 
considerations. [Ref. 5, p. 8.6] 

In managing the process and activities of CM, it is 
necessary that the requirements and provisions of the 
contractually imposed standards be incorporated into 
subcontractor statements of work (SOWs), including all 
elements of a comprehensive configuration management program. 
[Ref. 5, p. 8.4] 

The configuration change control process used by the 
contractor must [Ref. 5, p. 8.4]: 

1. Ensure effective control of all configuration 
items and their approved configuration identifications. 

2. Propose engineering changes to configuration 
items, request deviations or waivers for pertinent items, 
prepare software change notices (SCNs), and prepare 
notices of revision (NORs) on the appropriate form. The 
NOR is used only for proposing changes to documentation 
which required revision after engineering change proposal 
(ECP) approval. 

3. Establish a developmental configuration for each 
software configuration item. 

4. Maintain current copies of deliverable 
documentation and code. 

5. Provide the contracting agency access to documents 
and code under configuration control. 

6. Control the preparation and dissemination of 
changes to items under configuration control so that they 
reflect only approved changes. 

Changes to configuration items which have been placed 
under configuration control, by the contractor, are 
accomplished by submitting requests for waiver, deviations, 
NORs, and SCNs [Ref. 5, p. 8.5]. 
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Interface management, especially on large systems, may be 
handled by a separate interface or integration contractor. 
The prime development contractor's CM plan is required to 
describe either the contractor's interface identification and 
control, or the separately administered interface management 
program. [Ref. 5, p. 8.5] Contractor CM plans are delivered 
as a contract deliverable (CDRL) item subject to Government 
approval. [Ref. 5, p. 8.7] 

One of the specific standard requirements for a CM plan 
is to address, as a minimum, the configuration control, 
interchangeability, and interoperability for all Non- 
developmental Items (NDIs). [Ref. 5, p. 8.7] 

DoD Instruction 5000.2 sets policy to be followed by the 
program manager,- whereas the various standards establish the 
requirements for implementing that policy. Standards, not DoD 
directives and instructions, are imposed on contractors as 
contractually binding requirements documents to the extent 
specified in the acquisition documents. It is important that 
DoD directives and instructions not conflict with DoD 
standards since standards are imposed on contractors. [Ref. 
5, p. 8.8-9] 

Most systems are composed of one or more configuration 
items. A configuration item may be hardware or software, and 
it may be decomposed into lower-level sub-elements. 
Configuration items are classified as prime item, software 
item, critical item, or non-complex item [Ref. 5, p. 8.14]. 
Prime items are documented with type B1 and Cl specifications. 
Software items are documented with type B5a, C5, or B5b 
specifications. Critical items are documented with type B2 
and type C2 specifications. Non-complex items are documented 
with type B3 and C3 specifications [Ref. 5, p. 8.14-8.15], 
(See the section labeled MIL-HDBK-61 for additional 
information concerning configuration identification.) 

Firmware can be treated in configuration management as: 
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1. Non-developmental hardware and software. 

2. Non-developmental hardware and Government- 

developed software. 

3. Government-developed hardware and non- 

developmental software. 

4. Government-developed hardware and software. 

Each of these different mixes must be understood and both 
identified and controlled in light of their unique nature. 
This may mean references to the firmware identifications in 
either software specifications, and drawings or hardware 
specifications and drawings or both. [Ref. 5, p. 8.15 - 

8.16] 

The Government must be careful to invoke the level of 
configuration management necessary for the contract in the 
statement of work (SOW) . The SOW must identify the importance 
of the configuration management activity, and must describe 
the configuration management requirements in a separate and 
clearly identified section on the same level as other major 
development and management activities. [Ref. 5, p. 8.16] 

The SOW should state how the Government will interact 
with the contractor on the configuration management program. 
This will include whether or not the Government will chair 
technical review meetings, attend change control board (CCB) 
or software change control board (SCCB) meetings, attend 
interface control working group (ICWG) meetings, and conduct 
periodic audits of the configuration management system and 
specifications during the project. [Ref. 5, p. 8.16] 

2. DoD Directive 4245.7-M 

This directive, titled "Transition from Development to 
Production," discusses the importance of configuration control 
in reducing risk in a program. It denounces the direct 
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application of boilerplate policies and invoking military 
specifications which lead to ineffective control or overly 
complex and costly approaches to managing configuration. Many 
problems can be avoided by implementing a good configuration 
control system. A poor configuration control system leads to 
many pitfalls such as an unknown design baseline, excessive 
production rework, poor spares effort, stock purging rather 
than stock control, and an inability to resolve field 
problems. Poor configuration control is a leading cause of 
increasing program costs and lengthening procurement 
schedules. [Ref. 6, p. 3-30] A comprehensive CM policy will 
address the implementation of a configuration control system. 


3. NAVAIRINST 4130.1C 

This instruction, titled "Naval Air Systems Command CM 
Policy," implements SECNAVINST 4130.2 (referenced in 
NAVAIRINST 4130.1C). SECNAVINST 4130.2 will not be covered in 
this chapter since the interpretation of that instruction is 
embodied in the NAVAIRINST 4130.1C. NAVAIRINST 4130.1C 
establishes policy and assigns responsibility for CM. It also 
provides guidance for processing change proposals. It 
discusses CCBs and their structure and authority. The 
information presented in this subsection will concentrate on 
general CM policy rather than on detailed process guidance. 
NAVAIRINST 4130.1C is relevant to determining CM policy for 
NAWCTSD since NAVAIR is in the administrative chain of command 
for NAWCTSD. 

NAVAIR has designated NAWCTSD as an Office of Primary 
Responsibility (OPR). An OPR is assigned primary 
responsibility for system acquisitions. A designated OPR has 
certain authority and certain limitations regarding CM as 
provided in NAVAIRINST 4130.1C. Authority and limitations 
relevant to CM policy will be discussed in this subsection. 
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Most of the information presented in this subsection is quoted 
directly from NAVAIRINST 4130.1C. Although this information 
could simply be referenced, it is felt that readability of the 
overall thesis is improved by including the information in the 
body of the thesis. This both emphasizes information and 
limits it to that which the author felt was most important in 
determining CM policy. NAVAIRINST 4130.1C, because of its 
importance in determining CM policy for NAWCTSD is critical in 
defining what that policy should encompass. 

It is the policy that Class I engineering changes and 
major or critical deviations will be implemented only upon 
approval of a CCB. Rapid Action Minor Engineering Changes 
(RAMECs) will not be implemented prior to CCB approval. 
Configuration control requirements are to be included in 
acquisition documents per NAVAIRINST 4275.3F, "Implementation 
of Configuration Control," MIL-STD-480B, and MIL-STD-481. 
[Ref. 7, par. 4, p. 1] 

OPRs are responsible for [Ref. 7, par. 6.a, p. 2]: 

1 . providing CM of assigned Cis throughout their life 
cycle; 

2. preparing and maintaining CM plans for assigned 
CIS; obtaining approval of these plans, and assuring 
proper implementation of NAVAIRINST 4130.1C; 

3. managing and providing direction for the staffing 
of all engineering change proposals, RAMECs, and requests 
for major and critical deviations and waivers from 
initiation until submittal to a CCB; 

4. implementing CCB directed actions; 

5. maintaining the status of implementing actions for 
approved engineering changes, deviations, and waivers; 

6. conducting audits, establishing baselines; and 

7. establishing and maintaining an adequate 
configuration status accounting system. 
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The Configuration Management, Program Policy and 
Resources Division (AIR-100) has the authority to enforce 
NAVAIRINST 4130.1C. It also governs the CCB for the 
Commander, Naval Air Systems Command. AIR-100 governs the 
operation of ALL (author's highlight) existing CCBs and has 
the authority to charter subordinate CCBs. AIR-100 also has 
the authority to review and approve OPR CM plans. [Ref. 7, 
par 6.b, p. 2,3] 

Following are policy elements concerning CM during the 
acquisition phase [Ref. 7, par. 1.4, p. 1-1 - 1-2]: 

1. Concept Exploration and Definition (CE&D) Phase. 
Initial CM plans are formulated and the functional 
baseline is established. 

2. Demonstration and Validation (DEMVAL) Phase. CM 
plans are revised, functional baseline is updated, 
allocated baseline is established. 

3. Engineering and Manufacturing Development (EMD) 
Phase. CM plans are revised and functional and allocated 
baselines are updated. 

4. Production and Deployment/Operations and Support 
Phases. CM plans are revised, functional and allocated 
baselines are updated by a functional configuration 
audit, product baseline is established by a physical 
configuration audit, and the configuration status 
accounting record is coordinated with operating and 
support activities. 

When more than one Government activity is involved in the 
development, acquisition, modification, or support of a 
configuration item, a mutually approved CM plan will be 
included as part of the program interface agreement [Ref. 7, 
par. 1.5, p. 1-2]. 

The OPR will ensure that each contract for a Cl contains 
appropriate provisions for CM plans, Cl, CC, configuration 
audits, and CSA documents as outlined by NAVAIRINST 4130.1C 
[Ref. 7, par. 1.6, p. 1-2], 

If an OPR has more than one Cl under its management, the 
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use of an umbrella CM plan is recommended. An umbrella CM 
plan addresses the overall CM organization and planning which 
will be used. A separate addendum may then be prepared for 
each assigned Cl explaining and further tailoring specific 
policies and procedures to be followed to accomplish CM of the 
item. [Ref. 7, par. 2.2.2, p. 2-2] The author could not find 
reference to other organizations outside of the DoD. 

Separate CM plans will be required from each contractor 
who is developing and supplying hardware and/or software to 
the Navy. The OPR will assure that contractor CM plans are 
consistent with its own CM plans, NAVAIRINST 4130.1C, and with 
the total program needs. [Ref. 7, par. 2.3.1, p. 2-2] 

The OPR will schedule and conduct functional and physical 
configuration audits following MIL-STD-1521B. Normally, due 
to the nature and criticality of configuration audits, they 
will be performed by Government personnel. [Ref. 7, par.4.3, 
p. 4-1] The reader is invited to review Figure 4-1, page 4-2, 
in NAVAIRINST 4130.1C, for a complete (detailed) list of 
reviews and configuration audits to be performed over the life 
cycle of a system. It is not suggested that Figure 4-2 
contains information that should be included in a CM policy, 
however, the information is relevant to details for 
implementing CM policy and should become familiar to personnel 
required to implement CM under the authority of NAVAIRINST 
4130.1C. 

The OPR will ensure that provisions for configuration 
audits are included in each procurement contract, usually in 
the SOW [Ref. 7, par. 4.4, p. 4-1]. 

The authority to approve or disapprove Class I 
engineering change proposals, RAMECs, and major/critical 
deviations or waivers for PEO and NAVAIR managed items resides 
with the NAVAIR CCB, chaired by AIR-100. This authority may 
be delegated to an OPR for Class I engineering change 
proposals during the CE&D, DEMVAL, and EMD phases [Ref. 7, 
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par. 5.3.2, p. 5-1] . 

NAWCTSD is a full time associate member of the NAVAIR CCB 
[Ref. 7, par. 5.13.b, p. 5-9]. The remainder of MAVAIRINST 
4130.1C is concerned with details of change processes and 
other detailed implementing information. MAVAIRINST 4130.1C 
is a comprehensive document covering all aspects of CM for the 
NAVAIR community. The summary information presented in this 
subsection was gleaned to identify the salient points relevant 
to CM policy and implementation. The instruction is much 
broader in scope, however. 

4. DoD Instruction 5000.2, Part 9, Section A 

Because of the importance of DoDI 5000.2, the following 
paragraphs are quoted verbatim from the instruction. DoD 
Instruction 5000.2, under policies, states that an effective 
configuration management program shall be established to 
implement the decisions made in the systems engineering 
process by [Ref. 8, Part 9A, par. 2(a), subpar. 

(1) , (2) , (3) , (4) , p. 9-A-l] : 

(1) Identifying, documenting, and verifying the 
functional and physical characteristics of a 
configuration item, 

(2) Controlling changes to an item and its 
documentation, 

(3) Recording the configuration of actual items, and 

(4) Auditing the configuration item and its 
configuration identification. 

DoDI 5000.2, also under policies, states that 
configuration management shall be applied to any item [Ref. 
8, Part 9A, par. 2(b), subpar. (1),(2), p. 9-A-l,2]: 

(1) Developed wholly or partially with Government funds, 
including any Non-developmental Items (NDIs) when the 
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development of technical data is required to support off- 
the-shelf equipment or software, or 

(2) Designated for configuration management for reason 
of integration, logistics support, or interface control. 


DoD Instruction 5000.2, under procedures, describes the 
requirements of a configuration management program as [Ref. 
8, Part 9A, par. 3(a), subpar. (1),(2),(3), p. 9-A-2]: 

1. Procedures that must be tailored consistent with 
the complexity, criticality, quantity, size, and the 
intended use of the CIs. It requires the development of 
standard processes, and requires that these processes be 
used, but requires that they be tailored by means of the 
application of relevant military standards which are 
adapted to specific program characteristics. 

2. Configuration management activities conducted by 
the Government program managers during the acquisition 
program. It requires that these activities, initially 
conducted by the program manager, transfer to the various 
Service systems, logistics, or material commands when the 
Cl is transferred from the control of the program 
manager. 

3 . The processes and procedures established by mutual 
agreement, and documented by the lead DoD Component when 
more than one DoD Component is involved in the 
acquisition, modification, or support of the Cl. 

Configuration items will be directly traceable to the 
work breakdown structure [Ref. 8, Part 9A, par. 3.b, subpar 
(1), p. 9-A-2] The WBS handbook is being upgraded to include 
more details on the implementation of a WBS for software since 
this is not clearly defined in DoDI 5000.2 [Ref. 5, p. 8.9] . 

Configuration baselines will be used to ensure an orderly 
transition from one major commitment point to the next. These 
points are normally milestone decisions [Ref. 8, Part 9A, 
par. 3.c, p. 9-A-2]. 

Configuration changes will be controlled in accordance 
with MIL-STD-973. A configuration control board will be 
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established to review proposed changes to approved 
configuration identification [sic] and advise the Program 
Manager. [Ref. 8, Part 9A, par. 3.e, p. 9-A-3] 

5. MIL-STD-973 

MIL-STD-973, titled "Configuration Management," contains 
information that is generally at a level below that considered 
in this thesis for CM policy. Also, many of the sections in 
MIL-STD-973 are covered in other sections of this chapter and 
are appropriately referenced. The Military Project Management 
Handbook referenced MIL-STD-973 frequently but once again, the 
references were at the implementation level vice the 
programmatic or policy level. Therefore, although MIL-STD-973 
will be immensely important in the future for implementing CM 
on specific systems only one element is considered here for at 
the policy level as indicated in the following paragraph. 

Configuration management efforts are not considered 
peripheral to the overall systems development effort. 
Contractor CM personnel must participate in (not just attend) 
all technical reviews conducted [Ref. 9, para. 4.2.4], 

6. DOD-STD-2167A 

DoD-STD-2167A, titled "Defense Systems Software," states 
that the contractor shall perform configuration management in 
compliance with the following requirements [Ref. 10, Section 
4.5.2, p. 17] : 

1. Establish a development configuration for each 

computer software configuration item CSCI. 

2. Maintain current copies of the deliverable 

documentation and code. 

3• Provide the contracting agency access to 

documentation and code under configuration control. 
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4. Control the preparation and dissemination of 
changes to the master copies of deliverable software and 
documentation that have been placed under configuration 
control so that they reflect only approved changes. 

7. MIL-HDBK-61 

MIL-HDBK-61, titled "Configuration Management, " describes 
the life cycle related activities of CM from Concept 
Exploration and Development to disposition of a system. It 
states that there is a need to have CM purview of product 
development description documents as well as interface control 
drawings and documents. Interface documents may describe 
interfaces between hardware components and software components 
or between similar components. They may also describe 
interfaces between hardware and software. The important thing 
is that CM is presented in terms of a system and is 
accomplished for the life-cycle of the system. [Ref. 11, 
section 3.10, pp. 10-16] 

The following comments are the author's comments and 
opinion concerning the interpretation of MIL-HDBK-61 and MIL- 
STD-973. These opinions were formed during six years as the 
Site Manager of the F/A-18 flight simulator software support 
activity. It is important to note what is meant by software, 
both in MIL-HDBK-61 and in MIL-STD-973. Configuration 
management of software is concerned with what is contained on 
the media (whatever that media is such as tape or disk) not 
the media itself. Configuration management of software 
involves management and control of the source code and the 
executable image produced as a result of linking and compiling 
source code. Configuration management of software also 
involves management of the documentation for that software. 
Documentation must verify that the binary image and the 
documentation are consistent and at the same level. 

Software documentation can also be contained in the 
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source code used to generate the executable image and this 
should also be managed as a complement to the configuration 
management effort. Internal source code documentation such as 
comments added to the source lines of code should be used to 
identify changes and change requirements to the code and thus 
comprise an element of configuration management. 

This is mentioned here because many CM efforts involving 
software are aimed at controlling the media upon which the 
software is contained. Although the media must be controlled 
and is also a component of software configuration management, 
it is not the primary method of performing software 
configuration management. The key element is in managing and 
controlling the executable image and the source code that 
generates that image. 

Of all the elements of configuration management 
(configuration change control, configuration identification, 
status accounting, and FCA/PCA audits) configuration 
identification can easily be argued as the most important 
[Ref. 11, sec. 4.1, p. 21] . All of the elements of 
configuration control are based on configuration 
identification. If a configuration is not properly identified 
it cannot be controlled. 

Configuration identification is accomplished at three 
levels. They are: 

1. Functional Configuration Identification (FCI). 

The approved functional baseline plus approved changes. 

2. Allocated Configuration Identification (ACI) . The 

approved allocated baseline plus approved changes. 

3. Product Configuration Identification (PCI). The 

approved product baseline plus approved changes. 

The composite of these three elements constitutes the physical 
and functional configuration identification. 
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8. NASA Technical Memorandum 85908 


The technical memorandum is titled "Software Control and 
System Configuration Management: A Systems-Wide Approach." 
The NASA Ames Research Center developed a CM system that 
encompasses the whole of a system, hardware and software, in 
one process. The information in this section is a compendium 
of some of the important concepts from the NASA Technical 
Memorandum 85908 which is included in Appendix E. The entire 
document is included in the appendix, even though it is 
lengthy, since the concepts embodied in the approach to CM 
are, to this author, important for future consideration of an 
approach to CM from a systems concept. 

The Summary to the document states: 

A comprehensive software control and system 
configuration management process for flight- 
critical digital control systems of advanced 
aircraft has been developed and refined to ensure 
efficient flight system development and safe flight 
operations. Because of the highly complex 
interactions among the hardware, software, and 
system elements of state-of-the-art digital flight 
control system designs, a systems-wide approach to 
configuration control and management has been used. 
Specific procedures are implemented to govern 
discrepancy reporting and reconciliation, software 
and hardware change control, system verification 
and validation testing, and formal documentation 
requirements. An active and knowledgeable 
configuration control board reviews, and approves 
all flight system configuration modifications and 
revalidation tests. This report includes examples 
of configuration management forms and a description 
of the tracking process which ensures accurate and 
consistent records. This flexible process .has 
proved effective during the development and flight 
testing of several research aircraft and remotely 
piloted vehicles with digital flight control 
systems that ranged from relatively simple to 
highly complex, integrated mechanizations. 

The technical memorandum emphasizes the highly complex 
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interactions among hardware, software, and system elements. 
The solution was to develop a "systems-wide" approach to 
configuration control and management. NASA's experience with 
the use of separate hardware and software configuration 
control procedures was shown to be ineffective for highly 
integrated systems, such as digital flight control systems. 
NASA purports that the use of their systems-wide approach has 
been very successful and is more efficient than a separate 
hardware and software systems approach. 

The various phases of system development are described. 
They include definition of requirements, design, production, 
and ground and flight test. It is important to recognize that 
all of these phases are likely to require interactive 
development over the life-span of system and this is critical 
to implementing a good configuration management process. 

To properly manage these phases of development, an 
overall system configuration management process is needed in 
order to provide consistent treatment of software and hardware 
elements. This process addresses both software and hardware 
elements of advanced integrated systems and accommodates the 
inherent iterative nature of advanced digital flight control 
system development. The concept of a systems-wide approach to 
configuration control and management (which means that the 
same process is used for both software and hardware system 
elements) is a primary contributor to the successful 
application of this process on a number of highly complex 
aircraft systems. The reader is invited to read Appendix E, 
NASA Tech Memo 85908, System Development Phases, p. 3 to gain 
more detailed information concerning this subject and related 
subjects in the following paragraphs. 

Documentation provides a consistent and comprehensive 
method for documenting developmental changes. The primary 
goal of the documentation is to document changes implemented 
by all engineering disciplines involved in the project. 
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In the section labeled Status and Tracking, NASA states 
that an efficient method of tracking progress and generating 
status information is required for overall project management 
and scheduling purposes. 

The reader is encouraged to read the entire NASA 
Technical Memorandum to gain a better perspective on the 
details of the systems-wide approach and its application to 
several projects. This sub-section was included because most 
of the systems acquired by NAWCTSD are similar in nature to 
those described in the NASA Technical Memorandum. Integrated 
and highly interactive hardware and software systems are 
common. The problems addressed by NASA are similar to 
problems faced by NAWCTSD in the implementation of CM across 
a wide variety of systems. 

9. NSTS 07700, Volume IV, Book 1, Revision G 

The National Space Transportation System (NSTS) 07700 
(hereafter referred to simply as the NSTS document in this 
thesis, parts of which are included in Appendix D) provides 
the CM policy for the space shuttle program for both hardware 
and software. The space shuttle program is also called the 
National Space Transportation System or NSTS as in the title 
of the document. The following paragraphs present the major 
elements of CM as identified in the NSTS. The reader is 
invited to read Appendix D in order to obtain more details. 

The NSTS defines the requirements, responsibilities, and 
procedures for all Space Shuttle Program (SSP) 
elements/projects in the application of configuration 
management on the SSP including applicable contractor 
activities. 

Configuration identification determines the manner in 
which requirements for configuration is described. Formal 
documentation developed as a result of configuration 


43 



identification is used to describe baselines used for planning 
purposes and for control and accounting of future changes. 
Two general types of baselines are addressed, the "NASA 
baseline" and the "design activity/contractor baseline." The 
baselines are described and reference is made to the baselines 
developed as the program matures from the initial baseline 
which consists of program management and system performance 
baselines. The later baselines reflect developmental items. 
The amount of information contained in baselines is determined 
on an individual basis. 

At design freeze the configuration is established as 
verified through the development and Orbital Flight Test 
phases of the program. Change control is then initiated and 
baselines are expanded to include production drawings and the 
physical and functional configuration. 

A NASA acceptance baseline is developed from as-built 
configurations of the flight hardware and software. A Space 
Shuttle program baseline is developed which contains program 
requirements, Space Shuttle management requirements, system 
technical requirements, descriptive documentation, indentured 
parts listings, and other identification documents describing 
the configuration of all Space Shuttle hardware and software. 
A list of the types of data contained in the baseline is 
included in Appendix D, par. 3.1.4, p. 3-3. These items 
comprise essential elements of the configuration baseline. 

The remainder of section 3 discusses the Space Shuttle 
program definition and requirements baseline documentation, 
preparation, coordination, and processing of baseline 
documents, and interface control documents. 

Section 4.0 discusses configuration change control. It 
is in this section that change classifications are defined and 
the use of configuration control boards (CCBs) is discussed. 
The use of CCBs in performing elements of CM for the Shuttle 
Program is essential to NASA CM policy. CCBs are responsible 
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for approving all changes to shuttle hardware and software. 
There is a hierarchical system of CCBs in place to assure that 
both programmatic and detailed overview of changes is 
accomplished. 

The role of configuration accounting is defined and 
discussed. Configuration accounting is the element of CM that 
provides the essential records and reporting of precise 
configuration data for all Space Shuttle hardware and 
software. The configuration accounting system maintains, 
stores, and correlates the accounting data including change 
status and information. The system produces summaries and 
comparisons of data as needed for individual program elements. 
The control of interface control drawings (ICDs) is discussed. 
The role of the contractor or developer is defined. The NASA 
system allows developers to determine which drawings and/or 
ICDs may be affected by a proposed change. 

The Space Shuttle Program uses a data base called TDMS 2 
which contains current and historical data in the form of 
Interface Revision Notices (IRNs). This data base allows 
integration of diverse elements across the spectrum of 
projects, developers, and Government personnel involved in the 
Shuttle Program. Other configuration status reports and 
reporting requirements are identified. Mission essential 
software data retention requirements are identified. The 
software is required to be retained for three years. 

Part 6 of NSTS 07700, discusses the CM of requirements. 
It includes external agency requirements and interfacing 
requirements between program elements and projects. The need 
for reviews is discussed and it is stated that they will be 
conducted "as necessary." Reviews are also used to establish 
baselines. 
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10. Attachment 01 to Army Contract DAAH01-R-S079 


This sub-section is included and Appendix F is attached 
to provide an example of the approach that the Army Tactical 
Missile System (ATACMS) project manager is taking with respect 
to CM on that project. The reader is invited to read Appendix 
F to better understand the approach the Army is taking with 
respect to CM on the ATACMS project. 

The information presented in Appendix F would, prior to 
the Army's streamlining efforts in this area, have occupied 
many pages. The old method would have called for the 
application of standards and specifications. The functional 
specification contained in Appendix F is simple and concise. 
The performance specification is contained in MIS-38578 
Addendum II to the contract. The reader is invited to contact 
the ATACMS project manager if a copy of the performance 
specification is desired. 

The last page of Appendix F is a copy of a memorandum 
from the Army Acquisition Executive which addresses the 
delivery of contract data items. The memo requires that only 
one copy of each data item be delivered under a specified 
contract. It also states, "It is preferred and strongly 
encouraged that data items be delivered using electronic 
media." 

11. IEEE Standard 828-1983 for Software CM Plans 

Although this standard references plans rather than 
policy, the author felt that information regarding good 
software CM plans was important in understanding the part CM 
plans play in CM policy and CM policy implementation. 

The application of Software Configuration Management 
(SCM), together with Hardware Configuration Management (HCM) 
and overall systems configuration management, benefits all 
phases of the life cycle of a system containing software 
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components and is a matter of good engineering practice [Ref. 
12, Forward]. 

Plans document the methods to be used for identifying 
software product items, controlling and implementing changes, 
and recording and reporting change implementation status [Ref. 
12, sec. 1.1, p. 7] . 

Software Configuration Management Plan implementation 
major milestones include the establishment of [Ref. 12, sec. 
3.2.4, p. 9] : 

1. The configuration control board 

2. Each configuration baseline 

3. Schedules and procedures for SCM reviews and 
audits 

4. Configuration management of related software 
development, test, and support tools 

This paragraph contains information in the IEEE standard 
as it relates to implementing CM (or SCM) policy. Also 
provided in this information are examples of material which 
may be covered by policies, directives, and procedures and is 
therefore important to understand relative to overall CM 
policy recommendations resulting from this thesis. 

Applicable policies, directives and procedures shall 
[Ref. 12, sec. 3.2.5, p. 9]: 

1. Identify all applicable SCM policies, directives, 
and procedures which are to be implemented as part of 
this plan. The degree of implementation of each shall be 
stated. 

2. Describe any SCM policies, directives, and 
procedures that are to be written and implemented for 
this project. 

Examples of material which may be covered by policies, 
directives, and procedures are [Ref. 12, sec. 3.2.5 (2): 
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1. Identification of levels of software in a 
hierarchical tree 

2. Program and module naming conventions 

3. Version level designations 

4. Identification of specifications, test plans and 
procedures, programming manuals, and other documents 

5. Media identification and file management 
identification 

6. Document release process 

7. Turnover or release of software products to a 
library function 

8. Processing of problem reports, change requests, 
and change orders 

9. Structure and operation of configuration control 

boards 

10. Release and acceptance of software products 

11. Operation of software library systems to include 
methods of preparing, storing, and updating modules 

12. Auditing of SCM activities 

13. Problem report, change request or change order 
documentation requirements describing purpose and impact 
of a configuration change, or both 

14. Level of testing required prior to entry of 
software into configuration management 

15. Level of quality assurance,- for example 
verification against development standards required prior 
to entry into configuration management 


This list includes many items applicable to both hardware and 
software configuration and thus constitutes a list of possible 
essential CM policy elements. 

For each change control board and other change management 
bodies [Ref. 12, sec. 3.3.2.3, p. 10]: 
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1. Define the role of each; for example, change 
review authority 

2. - Specify their authority and responsibility 

3 . Identify the chairperson and the membership in the 
organizations, if the organizations have been formed 

4. State how the chairperson and the members (and 
alternates) are to be appointed, if the organizations 
have not yet been formed 

5. State the relationships of the developers and the 
users to the CCB(s) 

The above information can be applied to hardware CM as well as 
software CM and thus represents candidates for essential 
elements of CM policy. 

State the methods to be used for configuration control of 
interfaces with programs/projects beyond the scope of this 
software configuration management plan. If the software 
changes are required to be reviewed by other boards or teams 
prior to or in addition to the CCB(s), this subsection shall 
describe these board (or team, or both) and their relationship 
to the CCB(s) and to each other. [Ref. 12, sec. 3.3.2.4, p. 
10 ] 

State the control procedures for associated special 
software products, such as non-released software, off-the- 
shelf software, user furnished software, and in-house support 
software [Ref. 12, sec. 3.3.2.5, p. 11]. 

Identify, state the purposes, and describe (within the 
developers scope of proprietary rights) the use of the 
specific software tools, techniques, and methodologies to be 
employed to support SCM on the specific project [Ref. 12, 
sec. 3.4, p. 11]. 
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B. SUMMARY OF RESPONSES 


The responses to interviews conducted by the author of 
this thesis is summarized in this section. The interviews 
were conducted in an informal manner. Each person interviewed 
was asked what they felt were the essential elements of a CM 
policy and were invited to provide answers without prompting. 
Additional questions were asked depending upon the person 
interviewed and their involvement in developing CM policy. 
Some of those interviewed were also asked about the use of a 
Work Breakdown Structure (WBS) in the identification of CM 
items. 

All interviews except those conducted at NAWCTSD itself 
and at the Naval Postgraduate School, were conducted over the 
phone. It was planned that most of the information to be 
derived from the comparable industry and Government sources 
would be derived from written literature sent to the author. 
Such was the case. Facts derived from written material 
received by the author will be summarized in the next section. 

The interview with NAWCTSD personnel revealed that there 
was concern that CM was not uniformly implemented across the 
broad spectrum of devices supported. The author interviewed 
personnel involved in developing and maintaining the 
Configuration Management Information System (CMIS) at NAWCTSD. 
The same personnel were tasked to write the upgraded 
NAWCTSDINST 4130._M and will also have input to the 
development of the NAWCTSD CM policy statement in its final 
form. Other personnel interviewed were Project Directors and 
the Department Head and Deputy Department Head of Competency 
3.0, the logistics support competency. The following 
paragraphs summarize their answers to questions and also 
provides data that was provided ad hoc to the author of this 
thesis during the interviews. 
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1. NAWCTSD MANAGEMENT 


The Competency 3.0 Department Head and his Deputy had an 
appropriately long term, strategic outlook on the 
implementation of CM and the development of a good CM policy 
at NAWCTSD. They were also appropriately concerned with 
systems for the life-cycle of the system rather than just 
during acquisition. They discussed CM in the "out years" 
(years beyond the acquisition phase for Cognizance 2"0" 
systems) and they felt that a study would have to be done to 
address the issue of long term CM support. They identified 
the following areas of interest as potential study questions. 
These questions identify their concerns for CM implementation 
and CM policy, and also suggest study topics for this thesis 
and for possible future studies of a similar nature: 

• What do we, NAWCTSD, want to achieve in the area of CM? 

• To what level do we want CM accomplished on a given 
system or on the broad base of systems supported? 

• What architecture should be recommended or required? 

• Who are the customers for CM results, data, baselines, 
and information, both internal and external? 

• What other organizations are successfully performing CM 
and what is their policy? 

• What is the role of the field (ISEOs) and other 
competencies in the implementation of effective CM 
policy for NAWCTSD? 

• What automated equipment should be employed in 
performing CM? 

2. NAWCTSD CM PERSONNEL 

Personnel involved in writing and implementing CM policy 
at the branch level at NAWCTSD were interviewed to determine 
their view of the challenges presented in implementing CM. 
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Following is a summary of their comments and concerns. 

The CMIS system was developed as a local effort of 
NAWCTSD.- It has served the purpose for which it was 
developed, primarily to serve as a repository for CM 
information in support of the TECCB, but has not kept pace 
with technology in the area of data base design. It is 
difficult to modify this data base to perform additional 
functions as demanded by both internal and external customers. 
One of the major tasks faced by personnel involved with the 
CMIS was to either modify it to meet new requirements or to 
recommend the development of an alternative Configuration 
Management Information System. A new system would be costly 
and would require time to develop and get on line. This 
information is provided simply to provide a more complete 
picture of the challenges and their priority at NAWCTSD in 
developing a comprehensive CM policy including the systems and 
personnel needed to assure that the system will function now 
and in the future. 

On the surface, information concerning the CMIS system 
does not appear to be relevant to the development of CM policy 
for NAWCTSD. However, personnel involved in implementing that 
policy place the development of facilitating tools at a high 
priority in their work. The development of a CM policy at 
NAWCTSD is not dependent upon any particular type of system 
employed to perform the tasks to be determined, but whatever 
system is employed will be a factor in the success of any 
policy that is developed. Therefore, this information is 
germane to the development of policy since it is of great 
concern to those involved and will contribute, ultimately to 
the success of the policy implemented. This thesis will not 
attempt to recommend that any particular CMIS system be used 
at NAWCTSD but will assume that a satisfactory system is in 
place to support the goals of the resulting policy. 

Other concerns of the personnel "in the trenches" was 
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that whatever policy was developed, it had to account for the 
diversity of the customer data base, both internal and 
external-. And, that it should be written in unambiguous terms 
to assure the same interpretation by all personnel involved in 
CM. They want the policy to clearly define responsibility and 
to clearly define governing instructions. 

The problem of who, that is exactly which competencies 
within NAWCTSD, will perform what functions is important to 
the personnel interviewed. This is, apparently, a long term 
question to be resolved and one which this thesis may only 
partially answer. 

Other concerns of the personnel interviewed were of a 
specific nature concerning CM as it is practiced. The 
concerns were at a level which this thesis will not attempt to 
answer and therefore, those comments are not summarized here. 

3. Army TACMS (ATACMS) PROJECT MANAGER 

The past ATACMS project manager was interviwed. He is 
now a Senior Guest Lecturer at the Naval Postgraduate School. 
When asked what the Army CM policy was for the ATACMS system 
it was stated that CM was done by the contractor with 
Government control (chairmanship) of the Change Control Boards 
(CCBs). The project manager (PM) is a member of the CCB for 
life. This is how the Government maintains control of the 
system configuration. Prime contractors with sustaining funds 
have continuity and can thus perform CM best for the life 
cycle of the system. 

The following paragraphs summarize ad hoc comments 
concerning CM and CM policy. 

The weakest part of the CM effort was in performing good 
physical configuration audits (PCAs). The second PCA that was 
performed on the emergent system was done incrementally (in 
pieces, in a controlled fashion). This method delivered 
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better results than the first effort. 

A good CM plan is essential to the acquisition and life- 
cycle support of the system (of any system). The advent of 
the Computer-aided Acquisition and Logistics System (CALS), 
when fully implemented, will help improve our (Government and 
contractor) CM efforts. 

During the interview the author was presented with and 
discussed the contents of several handouts. Following is a 
brief summary of the CM related issues discussed and contained 
in those handouts: 

• Logistician(s) must influence the CM plan, change 
control process, and program funding to maintain PM- 
owned equipment in most current production 
configuration. (This equipment is frequently used to 
support engineering services during the production and 
deployment phase.) 

• Logistician (s) must ensure that the CM plan imposes 
change control on all common-use manufacturer's tooling 
and Software Test Equipment (STE) and Automatic Test 
Equipment (ATE). 

4. ATACMS Configuration Manager 


Following is a summary of discussion and ad hoc comments 
provided during a telephone interview with the ATACMS CM 
manager. 

CM policy for the ATACMS is different today than it was 
just a few months ago. The Perry Memorandum [Ref. 1] has 
changed the way the ATACMS program is doing business. 
Following is a summary of comments concerning this issue: 

• No "how-tos" only "what-tos" in contractual documents. 

• The Army Acquisition Executive (AAE) is adamant that 
PMs limit use of military standards and specifications. 
(See Appendix F) 

• PMs are to use only functional or performance 
specifications not military specifications or 
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standards. (See Appendix F for an example) 

• The part of the ATACMS Statement of Work (SOW) that 
addressed CM used to be very specific and was contained 
on many pages. It is now not specific and is contained 
on less than one-quarter of a page. It says what we 
want from the contractor, not how we want the 
contractor to do CM. (See Appendix F) 

• In the instructions to bidder, the word "plan" is out. 
The words "technical approach" are preferred including 
the contractor's technical approach to CM. 

• The Government used to be carried away with format, 
that is not so now. 

• The contractor's technical approach will include a CM 
technical approach. 

• The ATACMS program will no longer use ECPs as a measure 
of performance. 

• The contractor should still have the same type of 
information necessary to accomplish CM in the technical 
approach, in fact, they may still use one of the 
military standards such as MIL-STD-973. 

The ATACMS plan is to do Physical Configuration Audits 
(PCAs) and Functional Configuration Audits (FCAs) as a team 
effort with the contractor. One of the lead team members will 
be the Defense Plant Representative Office (DPRO) 
representative who will be on the team from the beginning of 
the acquisition until the end. 

It is important to determine the baseline while building 
the product instead of attempting to determine the baseline 
after the product is built using a PCA/FCA. 

The Work Breakdown Structure (WBS) should be used to 
establish a configuration breakout of the system. Care should 
be exercised since this is a contractually controlled item and 
may not be the same for all programs. The level, detail, and 
other items may differ and may not provide adequate 
decomposition of the system to accommodate CM requirements. 

The contractor must have drawings under a CM system. 
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The Government needs some type of automatic data access 
to the contractor's data on the project. Ultimately, the 
ATACMS CM manager would like to have the same exact data base 
that the contractor is maintaining. The Government should let 
the contractor know what the Government needs and have the 
contractor build the data base and access to the data in the 
data base. It could be that the Government could have 
automatic uploads of data from the contractor based on needs. 

As companies automate and get CALS compliant, the cost of 
doing business should decrease. The initial cost of becoming 
CALS compliant should then be reduced to reflect this 
decreasing cost as the project progresses. The Government 
should leverage this to keep the initial cost of "going CALS" 
to a minimum. 

5. Loral Corporation, Manager, Space Shuttle Project 
Coordination 

Following is a summary of responses to questions 
concerning Loral's CM policy for its Shuttle Software Support 
Operations in Houston, TX. Appendix G contains two sections 
from Loral's "Space Shuttle Onboard Software Program 
Management and Control Process." These sections provide 
additional information to that provided below. 

Loral has a CM policy, but it is not written as an 
overall CM policy for Loral. CM is totally ingrained in the 
entire process of software development and in everything they 
do in support of the Shuttle software. In fact, it is 
critically important to the CM effort, that the process itself 
be under CM, as it is at Loral. 

Loral has a mature, documented software development 
process. It was developed with NASA's involvement and was 
recently rated at a Capability Maturity Model level five by a 
NASA team trained to perform software assessments at the 
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Carnegie Mellon University, Software Engineering Institute. 
In December of 1994, the project received an unconditional 
International Standards Organization (ISO) 9000 certification. 

Loral does not do hardware configuration for the shuttle 
program. Hardware information that impacts software (extant 
or in development) at Loral, is passed to Loral from the CCB 
(NASA CCB with the hardware contractor as a member of the 
board) . 

Loral does not use an automated CM system in the 
development of Shuttle software. One reason is that the 
process was started in the 1970s before good Computer Aided 
Software Engineering (CASE) tools were available. Also, Loral 
uses HAL, a custom language developed by Loral. They also use 
a locally developed CM system. 

6. NASA Shuttle Hardware CM Manager 

Following are general comments concerning the most 
important elements of hardware CM as practiced by NASA on the 
shuttle. When asked if there was a written overall or policy 
statement it was stated that CM policy was a derivative of DoD 
policy tailored to NASA's needs. Their policy is contained in 
the NASA Space Transportation System 07700, Volume IV, Book 1, 
Revision G (see Appendix D) . The following paragraphs contain 
information provided on an ad-hoc basis concerning essential 
elements of CM policy. 

The project manager maintains authority over delivered 
hardware. This is what "drives" the system. 

CCBs meet daily to control all changes. 

Communication is required between shuttle hardware and 
software groups in order to assure that changes made to either 
are both known and controlled. 

Most of the CM work is done by the various hardware 
contractors. For the shuttle space system, they maintain just 
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one data base. The engine and tank CM data base is separate. 
They recommend one central data base if at all possible, with 
input direct from the contractor or that the contractor 
provide the data base and give access to the Government. 

For any new undertakings, an automated CM system should 
be required. For older systems it is not economically viable 
to change from a manual system to an automated system. 

7. NASA Shuttle Software CM Manager 

When asked if NASA had a written or overall CM policy the 
reply was that the policy was contained in multiple documents 
that implement CM for the Shuttle. However, the document 
included in Appendix D is for the Shuttle Space Program and 
presents an overall policy. Contractors do most of the CM on 
the shuttle. NASA has members on or chairs multiple CCBs to 
control the requirements and thus the configuration of each 
Shuttle since each one that flies is different in many ways 
from the last. 

Policy is also contained in multiple software and 
hardware management plans. The purpose, scope, definitions, 
and phases of software management are contained in the CM 
plans implemented as a result of the NSTS 07700 document (see 
Appendix D) . Contractor CM plans are important in determining 
overall Shuttle CM policy. They may indeed, be the backbone 
of CM policy for NASA, not withstanding the NASA Technical 
Memorandum 85908 referenced in this thesis and the NSTS 07700 
included in Appendix E which is specific to the Shuttle 
Program. 

Hardware changes are evaluated for software impact by 
"smart" hardware engineers, both within NASA and by their 
contractors. When a hardware change impacts software the 
software personnel are asked to look at the change that is 
being proposed. If software personnel agree that a change is 
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necessary, the information goes to a CCB for approval and 
scheduling. This direct information exchange system ties the 
hardware- system to the software system and integrates the CM 
systems of both. 

8. NPS Professors 

The following information is an integration of comments 
received from two professors at the NPS. Both professors are 
members of the Information Systems Engineering and Management 
Group in the Systems Management Department. One teaches 
Software Configuration Management and has done studies for the 
NASA Shuttle project. The other teaches Management 
Information Systems and is expert in the principals of CM as 
practiced in industry and the Government. 

One professor felt that the use of a WBS in developing a 
CM policy for systems is preferred mostly by high level civil 
servants to aid in metrics for measuring system costs and for 
describing the system at a high level. It can be of aid in 
developing a CM system but care must be used in trying to 
adapt it to CM use. It is used primarily for identifying 
costs and therefore may not be an optimum decomposition of the 
system for purposes of CM. 

They recommended the use of automated CM tools as much as 
is practicable within program constraints (dollars) . It would 
be best to use some standard in requiring an automated system, 
but we should not specify any particular system. The best 
approach is to use standard data elements to assure that all 
projects provide the necessary configuration management 
information to the level desired. 

CCBs should have Government members on them or should be 
chaired by a Government member. A discrepancy control board 
should be established. Absolutely all changes to the system 
must be documented including requirements for the changes. 
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All documents, organizations, people, and requirements 
should be traceable from program inception to disposition of 
the system at the end of-its useful or supportable life. 

CM policy should be developed early in the program. We 
must determine exactly what we are trying to manage when 
determining the composition of a CM system. We should manage 
and define all interfaces in the system as well as discreet 
system elements. We should manage specifications (as 
applicable in the new acquisition environment). We should 
manage both hardware and software. 

There must be both a • functional and physical 
decomposition of the system. 

The decision process must be identified and managed. We 
must also know exactly what data we need. 
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VI. ANALYSIS 


The derivation of answers to the research questions are 
a produc-t of deduction and induction and represent a whole 
derived from many different parts. This thesis is structured 
to provide answers specific to the needs of NAWCTSD with 
respect to an over-arching CM policy thus is broad in scope. 
Individual competencies within NAWCTSD may find the answers 
too broad to assist them in implementing the resultant policy. 
For those individuals, it is recommended that they study the 
references in this thesis with an emphasis on military and 
commercial standards for more specific information concerning 
implementation at the working level. 

A. ESSENTIAL ELEMENTS OF CM POLICY 

There is general agreement by the sources studied for 
this thesis that CM comprises four major elements. They are 
[Ref: 13, p. vi-vii]: 

1. Configuration Identification. Selection of the 
documents which identify and define the configuration 
baseline characteristics of an item. 

2. Configuration Control. Controlling changes to the 
configuration and its identification documents. 

3. Configuration Status Accounting. Recording and 
reporting the implementation of changes to the 
configuration and its identification documents. 

4. Configuration Audit. Checking an item for compliance 
with the configuration identification. 

This definition is in concert with the definition provided in 
DoD 5000.2 and other instructions, but it is provided in terms 
that are clear and perhaps more easily understood. It is 
provided in this chapter to identify clearly the major 
elements of CM. The reader is invited to compare this 
definition with that provided in Appendix C (from NAWCTSDINST 
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4130._M) which includes the same elements but is in more 
technical terms. The definition in Appendix C also addresses 
digital - data files. It is the same as that found in 
NAVAIRINST 4130.1C. The importance of the definition found in 
Appendix C versus that provided above is that the present 
policy of NAWCTSD is in consonance with technical treatises as 
well as the definition of CM in NAVAIRINST 4130.1C. The 
bottom line is that CM policy must address these four areas as 
well as the additional area of digital data files which is not 
included in the list of CM elements above. 

B. CM REQUIREMENTS PER DoN, DoD, AND OTHER FEDERAL 
REGULATIONS 

In order to discuss DoN, DoD, and other federal 
requirements it is important to establish which instructions 
are superior. For purposes of this thesis NAVAIR is the 
governing agency which determines CM requirements and thus CM 
policy for NAWCTSD. There are no conflicting instructions 
regarding CM policy and implementation. 

The author found NAVAIRINST 4130.1C to be a comprehensive 
document which references SECNAVINST 4130.2 a superior 
instruction, hierarchically, which requires NAVAIR to 
establish CM policy, procedures, and guidance in processing 
engineering changes. 

Department of Defense Instruction 5000.2 was not listed 
in the list of references in the cover letter to NAVAIRINST 
413 0.1C. It is, however, the basis for Appendix D in 
NAVAIRINST 413 0.1C which provides information concerning CM of 
mission-critical computer software. DoDI 5000.2 is referenced 
in NAVTRASYSCENINST 4130.3 governing CM policy at NAWCTSD. 
Because of the importance of DoDI 5000.2 in determining 
acquisition policy, a part of which includes CM, that 
information is integrated into the following analyses. 

The general policies embodied in NAVAIRINST 4130.1C will 


62 


be relied upon to clearly establish the requirements for CM 
policy for NAWCTSD. Other elements may be determined to be 
requiredr in order to define a more comprehensive policy than 
that required in NAVAIRINST 4130.1C. The elements contained 
in NAVAIRINST 4130.1C are minimum requirements for CM. Those 
items not covered in NAVAIRINST 4130.1C but which are included 
in DoDI 5000.2 and other documents studied, are discussed as 
appropriate in this and subsequent sections. 

NAVAIRINST 4130.1C addresses requirements for the 
aviation community. Since NAWCTSD serves other customers 
outside the NAVAIR arena, other .requirements may result from 
instructions extant at those outside agencies. Since those 
requirements may be dynamic and may differ from those 
contained in NAVAIRINST 4130.1C, it is outside the scope of 
this thesis to address them individually. However, the 
implementation of CM based upon DoDI 5000.2 and other military 
standards assures that other military agencies have derived CM 
requirements from at least some of the same documents used to 
derive the requirements for CM in NAVAIRINST 4130.1C. The CM 
policy for NAWCTSD, part of which is embodied in CM plans, may 
be modified as necessary to meet the needs of other agencies 
including those outside DoD. 

NAWCTSD is designated an Office of Primary Responsibility 
(OPR) [Ref: 14, par. 6, p. 4], Chapter V, page 9, of this 
thesis, lists the CM responsibilities for an OPR. That list 
of seven items represents the overall requirements of CM for 
an OPR and thus the minimum essential elements of CM policy 
for the NAWCTSD. Those requirements are not, however, 
inclusive of all of the elements that exist in DoN, DoD and 
other Federal Government regulations some of which, analysis 
indicates, should be included as essential elements in the 
resulting CM policy for NAWCTSD. 

The following paragraphs will list the seven items 
individually and will analyze the content of each for 
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applicability to CM policy at NAWCTSD. The seven items cover 
the essential elements of CM policy as identified in paragraph 
A. Other potential essential CM elements will be analyzed in 
subsequent paragraphs. 

1. OPRs are responsible for providing CM of assigned Cls 
throughout their life-cycle. To implement this as policy it 

is necessary to define CM and to determine what should be the 
defined life-cycle. Configuration Management is defined in 
NAVAIRINST 4130.1C. That definition is in agreement with 
other definitions in technical documents concerning CM such as 
the "Military Project Management Handbook." Appendix C lists 
the definition. Also included in the definition is the 
definition of how CM is applied to digital data files. 

The life-cycle of a system or Cl is defined in DoD 
5000.2. The life-cycle of systems is defined in phases 
beginning with the Concept Exploration and Definition phase 
and ending with disposition of the system at the end of the 
Operations and Support phase. Specific CM requirements, 
source documents, and baselines for individual phases are 
listed in Chapter V of this thesis and in NAVAIRINST 4130.1C, 
paragraph 1.4, p. 1-1. A comprehensive CM policy would 
include the information necessary to identify CM requirements 
during each phase of the system's (Cls) life-cycle. Other 
technical documents studied are in general agreement with the 
phases and their requirements listed in NAVAIRINST 4130.1C. 
Whether a system is acquired by NAWCTSD or is inducted into 
the NAWCTSD inventory, CM policy establish minimum CM 
requirements. Differences may exist based on CM systems 
established, or not established, in the acquisition phase of 
the system inducted into the NAWCTSD inventory. 

All documentation analyzed indicates that CM should be 
started as early as possible in the acquisition phase and 
should be continued for the life-cycle of a system. CM should 
be an integral part of the development of both the software 
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and hardware. Software is given special treatment both in 
NAVAIRINST 4130.1C and in the other technical documents 
researched. A comprehensive CM policy should state the 
requirements for contractors to perform CM on software in 
accordance with DoD-STD-2167A, Section 4.5.2, p. 17 and as 
listed in Chapter V of this thesis. It is important to 
recognize that CM on software should start early in the 
acquisition phase and that is why DoD-STD-2l67A should be 
identified clearly in a comprehensive CM policy. 

DoD-STD-2167A addresses CM from the contractor viewpoint 
and it is the contractor who will establish CM early in the 
acquisition phase, not the Government. It is recognized and 
stated in NAVAIRINST 4130.1C and in DoD-STD-2167A that 
standards are to be tailored as necessary to accomplish CM on 
a given system. 

Software CM requirements must clearly establish what is 
to be managed with reference to source code and the executable 
image. This will assure that contractors approach software CM 
efforts with a goal that correctly mirrors the requirements of 
the Government. Hardware CM requirements must also establish 
clearly what is to be managed. Configuration identification 
is considered one of the most important CM requirements for 
both hardware and software CM. If done properly CM will be 
more successful since what is to managed will be clearly 
documented and understood by all implementers. 

2. OPRs are responsible for preparing and maintaining CM 
plans for assigned CIs, obtaining approval of these plans, and 
assuring proper implementation of NAVAIRINST 4130.1C. 
NAVAIRINST 4130.1C requires that a CM plan be written for each 
Cl under the cognizance of an OPR. NAWCTSD has many CIs under 
its cognizance and therefore an umbrella CM plan is 
appropriate to cover this requirement [Ref: 7, par. 2.2.2, p. 
2-2] . 

Reference is made to IEEE Standard 828-1983 for 
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information specific to implementing CM plans for software. 
Applicable policies, directives, and procedures are identified 
and a list is provided of examples of material which may be 
covered by policies, directives, and procedures [Ref: 12, 
section 3.2.5] It is the author's opinion that the material 
referenced in the IEEE Standard and in NAVAIRINST 4130.1C, as 
discussed in Chapter V of this thesis, form the backbone of a 
comprehensive CM policy for software, tailored as necessary 
for individual programs. 

To cover individual CIs, a separate addendum may be 
prepared to explain and tailor policies and procedures to be 
followed to accomplish CM on an individual Cl. If the Cl is 
for an organization outside the DoD, it is the author's 
opinion that tailoring may have to be more substantial than 
for CIs falling under the DoD umbrella. However, this should 
not require an additional CM plan to be written just for those 
CIs. An addendum to the umbrella CM plan will suffice to 
tailor the plan to a specific Cl outside the DoD purview. CM 
plans for surface and sub-surface communities of the Navy 
which are serviced by NAWCTSD will require less tailoring of 
the umbrella CM plan but most likely require some tailoring. 

Overall CM policy must address situations where more than 
one Government agency is involved in the development, 
acquisition, modification, or support of a Cl. This requires 
that a mutually approved CM plan be included as part of the 
program interface document. [Ref: 7, par. 1.5, p. 1-2] CM 
policy, in order to be comprehensive should include provisions 
for joint endeavors. The policy can be included in the CM 
policy document by reference to the appropriate section of 
NAVAIRINST 4130.1C. 

The CM policy must also address support for systems 
inducted into the NAWCTSD inventory which were not acquired by 
NAWCTSD. Systems in this category will have to be surveyed to 
determine the extent of CM support developed during the 
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acquisition phases. Systems in this category will depend upon 
resources available to develop or sustain CM. They will, of 
course, -have to be supported in the same manner as other 
systems within the constraints introduced by available 
resources. 

3. OPRs are responsible for managing and providing 
direction for the staffing of all engineering change 
proposals, RAMECs, and requests for major and critical 
deviations and waivers from initiation until submittal to a 

CCB . This requirement is thoroughly documented in NAVAIRINST 
4130.1C and requires no significant analysis to implement. 
Questions related to this requirement are answered in the 
appropriate sections of Chapter V and in NAVAIRINST 4130.1C. 
Forms are provided in NAVAIRINST 4130.1C. Explanations for 
completing them and the process for routing them are clearly 
defined in NAVAIRINST 4130.1C, Chapter 6. Analysis of the 
instruction indicates that the process can be used without 
modification by NAWCTSD except for systems not under the 
purview of NAVAIR. Those systems should be adaptable to 
NAVAIRINST 4130.1C with minor modification to suite other 
agencies acting as custodians of the systems. 

The CM policy for NAWCTSD should include reference to the 
appropriate sections of NAVAIRINST 4130.1C, contained in 
Chapter 6, in order to implement the appropriate change 
control policy. 

In implementing this policy it should be remembered that 
AIR-100 has the authority to review and approve OPR CM plans 
for aviation owned CIs. In the case of non-aviation CIs, the 
agency owning the Cl will have to review and approve CM plans 
for that Cl. 

4. OPRs are responsible for implementing CCB directed 
actions. This requirement relates to the NAVAIR CCB chaired 
by AIR-100 and to CCBs chartered by and thus subordinate to 
the NAVAIR CCB as in the case of OPRs. Class I engineering 
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change proposals may be delegated to an OPR during the CE&D, 
DEMVAL, and EMD phases. The operation of CCBs is well 
documented in NAVAIRINST 4130.1C and requires little analysis. 
With relation to implementing policy concerning CCB operation 
and authority, the policy for NAWCTSD can be clearly 
identified by referring to the appropriate section in 
NAVAIRINST 4130.1C. 

5. OPRs are responsible for maintaining the status of 
implementing actions for approved engineering changes, 
deviations, and waivers. This requirement concerns 
documentation of actions approved or disapproved by a CCB. 
With regard to overall CM policy, NAVAIRINST 4130.1C 
adequately describes the process by which this requirement is 
accomplished. In the NAWCTSD CM policy, this can be 
adequately addressed by reference to the appropriate section 
in NAVAIRINST 4130.1C. 

A good configuration control system is necessary to 
reduce program risk. Chapter V provided the necessary 
elements of a comprehensive configuration control system from 
DoD Directive 4245.7-M. For purposes of configuration control 
implementation based on an adequate policy, reference should 
be made to DoD Directive 4245.7-M as presented in Chapter V. 

Because of NAWCTSD's extensive involvement with other 
Government agencies and with the surface and sub-surface 
communities within the Navy, the requirement for maintaining 
the status of implementing actions for approved engineering 
changes, deviations, and waivers is significant and may be 
more difficult to manage than it first appears. The NAVAIR 
policy assumes that the Cl is under NAVAIR cognizance. Since 
this may not be the case for many CIs, under the cognizance of 
NAWCTSD, a clarifying statement must be included in the policy 
to address the interface between NAWCTSD and other agencies' 
CCBs. The same procedural methods, or process, can be used 
for maintaining the status of implementing actions. It will 
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only be necessary to address the difference in the interfaces, 
data interfaces and organizational interfaces, between the 
agencies- to facilitate information interchange. 

6. OPRs are responsible for conducting audits and 
establishing baselines. The policy for conducting audits and 
establishing baselines should be contained in a CM policy 
statement. Since Government personnel will normally perform 
audits, CM policy should so state that fact and provide 
information detailing information concerning deviations from 
the policy. Policy should also identify the requirement that 
audits be performed over the life-cycle of a Cl including how 
often they must be accomplished. CM policy must require 
appropriate provisions in procurement contracts to clarify 
Government and contractor responsibilities during all phases 
of the system's life-cycle. 

Baseline establishment is dependent upon proper 
configuration identification. MIL-HDBK-61 identified 
configuration identification as the most important element of 
configuration management as identified in Chapter V of this 
thesis. Proper configuration identification is the key to 
configuration control. Thus, a comprehensive CM policy will 
assure that configuration identification is clearly given 
priority treatment in the development of CM plans and 
implemented CM systems. 

7. OPRs are responsible for establishing and maintaining 
an adequate configuration status accounting system. One of 

the problems in analyzing this requirement is in determining 
what is meant by the word "adequate." For purposes of CM 
policy, the author chooses to define "adequate" as a CSA 
system that satisfies the data requirements of all customers 
both internal and external to NAWCTSD. The definition of CSA 
in Appendix C is more specific since it includes the elements 
necessary to record and report information needed to manage 
configuration management effectively. The policy statement 
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need only reference the definition of CSA, as written in 
Appendix C, to assure that all elements of CSA are identified 
as required in the resulting system. 

Research indicates that a central data base is mandatory 
to implement this requirement. The data base should be robust 
enough to satisfy the needs of all users and customers both 
internal and external to NAWCTSD. It should also be designed 
to be accessible to both Government and contractor 
organizations in order to assure the most efficient input of 
data and availability of information suited to the specific 
needs of individual programs. 

Data specifications for a central data base should be 
included in acquisition and internal implementing documents 
such as Statements of Work (SOWs) and inserted in appropriate 
contracts to assure data commonality among the many CIs 
managed by NAWCTSD. This will also assure that the system is 
accessible by contractor and Government agencies as needed for 
review and input of data. 

For purposes of CM policy it is necessary to include a 
specific definition of the term CSA either as a reference or 
as an appendix to the policy. It is the experience of the 
author that CSA is viewed differently by every level of the 
implementing organizations. Implementers at the development 
or modification level require certain information, managers 
require different or summary information and so on up the 
chain of command. CM policy for the NAWCTSD must address the 
different levels of information requirements for individual 
users in order to establish a policy that is both adequate and 
effective for NAVAIR as well as other users and for those at 
the implementation and management stages and all users in 
between. 

In developing and analyzing CM policy it is important to 
remember that tailoring is a cornerstone of present 
acquisition policy. Tailoring of CM requirements is also 
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required in order to meet the requirements of multiple 
customers. In tailoring requirements, the limitations must be 
understood in order that essential or statutory requirements 
are not "tailored out." Authority of CCBs and other elements 
of CM may require waivers from NAVAIR AIR-100, in order to 
change them to suit a specific program. 

NAVAIRINST 4130.1C should be read and thoroughly 
understood by all personnel and competencies required to 
implement CM under the policy developed by NAWCTSD. If 
necessary, classes should be taught to enhance general 
knowledge of CM requirements and implementation strategies. 

One item that is not covered in the CM policy established 
in NAVAIRINST 4130.1C is the level to which CM is to be 
performed. DoDI 5000.2 states unequivocally that 
configuration items will be traceable to the work breakdown 
structure (WBS) [Ref: 8, part 9A, par. 3.b, subpar (1), p. 9- 
A-2]. No level is indicated in DoDI 5000.2. A work breakdown 
structure is required for acquisition programs which are 
defined in DoDI 5000.2. 

Based on the requirements in DoD 5000.2, a WBS should be 
used to provide at least an initial system description for 
configuration identification purposes. This requirement 
belongs in a comprehensive CM policy providing the limitations 
of work breakdown structures are known as described in Chapter 
V of this thesis. Furthermore, as a matter of policy, it 
would be counterproductive to require that the level be 
greater than level three, at least in the early stages of 
system procurement. Levels beyond level three are developed 
by the contractor (the first three levels are called a WBS 
summary level and are developed by the program manager) and 
may or may not be suitable to use for a decomposition of the 
system for configuration identification purposes. The use of 
the WBS beyond level three should be determined by the 
specific requirements of individual programs and by available 


71 



resources. 

As a final note of interest in this section, it must be 
remembered that the Perry Memorandum [Ref. 1] is having far 
reaching effects on the way the Government acquires and 
manages systems. CM will be affected as the Government 
emphasizes the use of NDI and COTS and as acquisition 
streamlining efforts materialize. NAVAIR policy will reflect 
these changes as appropriate and at a time when it becomes 
necessary to address them. The author cannot forecast how the 
changes will affect CM policy in the long run. It is almost 
certain, however, that CM policy as it is written today will 
be altered to accommodate heavy contractor and industry 
involvement in performing CM functions. A look at the 
following section will indicate what is already happening on 
at least one other Government procurement with regard to 
contractor involvement in CM. 

C. CM POLICIES FOR SIMILAR GOVERNMENT ORGANIZATIONS AND 
INDUSTRY FIRMS 

1. Army Tactical Missile System (ATACMS) . This program 
is using the contractor to perform CM functions. Government 
involvement is through CCB chairmanship and membership. This 
arrangement simplifies the resulting CM policy as is reflected 
in Appendix F which contains the entire contractor CM 
requirements in approximately one-fourth of a page. The 
requirements are in the form of functional requirements and 
thus eliminate military standards and specifications. This is 
in keeping with the desires of the Army Acquisition Executive. 

Analysis of the CM requirements in the SOW indicate that 
the ATACMS program is simplifying Government responsibility in 
the area of CM policy and management of the CM process. The 
ATACMS CM manager has changed the approach to CM as practiced 
prior to the advent of the Perry Memorandum [Ref. 1] and in 
response to the Army Acquisition Executive. It is evident 
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that the requirements for CM, from a policy perspective, are 
that present and future requirements for CM on the ATACMS 
system is entirely functionally based, contractor operated 
with Government CCB chairmanship, greatly simplified, and 
requires fewer deliverables than would previously have been 
required. 

2. Loral Corporation. CM policy is embedded in their CM 
process. The emphasis on CM is that their process is itself 
under CM. CM is a state of mind and is prevalent in 
everything they do to produce the software vital to the 
Shuttle system. This may not. be applicable directly to 
NAWCTSD's CM policy since NAWCTSD's policy is largely governed 
by higher echelon instructions. The information concerning 
the successful implementation of policy as practiced by Loral 
is excellent for study of future CM policy and for a level of 
contractor involvement in the CM process. 

3. NASA. Both the hardware and software CM systems for 
the Shuttle system rely heavily on contractor involvement in 
the process. The only direct Government involvement in 
performing CM is in determining the requirements for CM in 
contractual documents and in chairing and performing as 
members of CCBs. NASA also requires that contractors maintain 
appropriate data bases to facilitate information requirements 
for both NASA and the contractor. 

Research indicates that this has been a wholly successful 
approach to CM. The Shuttle system is one of the most complex 
systems in existence today. The configuration changes with 
each flight. Configuration management is critical to the 
success of the system. The system is not plagued by 
incompatibilities between the diverse parts of the hardware 
and software nor is it plagued by incompatibilities between 
contractor delivered material or software as indicated by the 
interviews conducted. This is an indication of the success of 
CM as practiced on the Shuttle system. 
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NASA's whole systems approach, included in Appendix E, 
is a radical change from that being employed currently. The 
idea of -integrating the software and hardware CM process is 
appealing. First, it eliminates the idea of requiring two 
types of CM systems or processes to perform the same type of 
job. As stated in Chapter V of this thesis, there are many 
similarities in the requirements for performing CM on hardware 
and on software. The NASA whole systems approach recognizes 
the similarities and leverages them to accomplish CM in a 
simpler, more efficient, and ultimately more manageable CM 
process. The Total Quality Leadership adage is that we should 
concentrate on the process, not the product. That is what 
NASA has accomplished in its whole systems approach. 

Although NASA's approach may require too much change in 
the present NAVAIR and NAWCTSD systems, analysis of the 
approach indicates that it has many attractive features and 
could be a subject for future theses on this topic. 

D. SIGNIFICANT PROBLEMS AND ISSUES UNIQUE TO NAWCTSD 

Analysis of the data indicates that the problems 
associated with implementing CM at NAWCTSD are exacerbated by 
the diverse customer base, a huge inventory of systems, and a 
complex interface between NAWCTSD competencies and between 
internal and external customers. The following paragraphs 
analyze those problems. 

1. Organizational Problems 

NAWCTSD is in the midst of a major change in its 
structure. Under NAVAIR guidance, the entire NAVAIR team has 
been designated as a Competency Aligned Organization (CAO). 
This thesis will not address the implementation of NAWCTSD as 
a CAO in any detail, it is simply noted that this change 
represents a major change in the "way we do business" and thus 
complicates the process of implementing CM policy both as it 
exists and with any modifications that may result from 
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information and recommendations derived from this thesis. 

In addition to the instability introduced by changing to 
a CAO the accomplishment of configuration management is 
complex and involves many different competencies and 
individuals. When the diverse customer base is factored in to 
the already complex internal interfaces required to accomplish 
CM it is evident that there are and will be organizational 
problems. Some of those problems were evident from the 
interviews conducted at NAWCTSD as indicated in Chapter V of 
this thesis and some are the result of analysis of present and 
potential future problems. 

One of the major question concerning implementation of CM 
policy is determining who (which competency) is responsible 
for CM at NAWCTSD. There are two parts to this question. One 
part is who is responsible for managing CM and the other is 
who is responsible for implementing CM at the working level. 

Competency 1.3.2 is responsible for policy and oversight 
as well as CCB chairmanship and CCB charters. All other 
competencies are implementers of CM policy. A clear cut 
charter for every competency involved in implementing CM at 
the working level must be included in any CM policy. The 
charter must explicitly identify the requirements of that 
competency with respect to CM implementation. Program level 
requirements such as a central data base must be addressed and 
managed by Competency 1.3.2. 

Until recently project management may have viewed CM 
primarily from an acquisition perspective, not from a life- 
cycle perspective. Project management is now responsible for 
acquired systems from the concept exploration phase till 
disposal. This change requires that project management view 
the CM process as a continuum from the acquisition phase until 
system disposal. This means that at any given time in a 
program, the emphasis on CM will change depending upon the 
phase of the system's life-cycle. CM plans are dynamic and 
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should be updated at each phase and thus organizational 
requirements should be updated at each phase to accommodate 
the lifer-cycle phase of the system. If properly addressed in 
the charter for every competency, with respect to individual 
systems, the problem of who is responsible for CM 
implementation at the working level should be answered. As 
indicated in Chapter V of this thesis, the project manager 
should be assisted by the assigned logistician in determining 
CM requirements for individual systems. This hopefully 
symbiotic relationship should be continued throughout the 
life-cycle of the system. 

The responsibility of some competencies such as In- 
Service Engineering Offices (ISEOs) or logistics competencies 
will be different because of customer interface and customer 
requirements. Also, ISEOs actually perform engineering 
modifications to systems as well as support system 
acquisition. Most competencies will have complex interfaces 
with customers including both internal and external NAWCTSD 
customers. An overall CM plan with addenda used to tailor or 
modify them to specific programs will answer the question of 
who is responsible for implementing and who is responsible for 
managing CM at NAWCTSD based on which competency is 
responsible during a particular life-cycle phase. A CM plan 
is required by NAVAIRINST 4130.1C and, since NAWCTSD manages 
many configuration items, a master plan with addenda is both 
authorized by the instruction and as far as this author is 
concerned is mandatory for implementation of a comprehensive 
CM policy. 

Analysis of data indicates that involvement by upper 
level management is necessary for any CM plan or process to 
work. CM as practiced in many organizations is not given a 
high priority by upper level management. Following is a quote 
concerning the involvement of upper level management in the 
commercial sector [Ref: 15, par. 10.1.6, p. 10-3] 
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Successful major systems programs in the commercial 
acquisition environment are the product of 
unequivocal top-management approval and support. 

In-projects reflecting the strategic emphasis of 
the company, there is clear linkage to 
organizational business strategy and a direct 
involvement of the CEO. Involvement does not mean 
micro-management, but it does mean awareness of the 
project's current status, an active questioning, 
and willingness to commit the organization's 
resources to resolve problems. 

This commitment by upper management can be applied to 
Government as well as commercial organizations. In the case 
of NAWCTSD, project managers must be committed to CM 
implementation as an adjunct to their management tools as well 
as a life-cycle cost saving strategy. 

Given a clear cut charter for all competencies involved 
in managing or implementing CM at NAWCTSD, an umbrella CM plan 
with addenda, and commitment by upper level management to the 
tenets of CM, the question of who is responsible for CM and 
who will implement CM will be answered clearly. This will 
eliminate many of the organizational problems extant at 
NAWCTSD. 

2. CM Concept Interpretations 

A question that has arisen frequently regarding CM policy 
concerns the level to which CM is to be done. It is important 
that this question be answered as a matter of policy because 
this question involves the distribution of scarce resources. 
Analysis indicates that as a matter of policy there can be no 
single answer to this question. The answer to the question 
was not provided by analysis of data in this thesis. 
Deductive reasoning provides a partial answer which may be 
made a matter of policy. 

Department of Defense Instruction 5000.2 requires that 
configuration items be directly traceable to the work 
breakdown structure. Although the level of CM is not 
specified it is evident that the level is dependent upon the 
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system's life-cycle phase. As a minimum, however, the summary 
WBS level should provide a good starting point for identifying 
the level of CM to be performed. Beyond that level, which is 
three levels deep, specific program requirements will 
determine the level to which CM is to be performed. Usually, 
this will be determined by the amount of resources available 
in a given program to support the decomposition of the system 
into elements that are sufficiently detailed to adequately 
describe the system and to facilitate CM. 

The level may be different based solely on customer 
requirements. Once again, customer requirements will, most 
likely be based on available resources. The difference 
between resources required and resources available for CM will 
be no different in the determination of the CM system adapted 
than to any other element of acquisition or life-cycle 
support. 

CM over the life-cycle of systems was identified in 
interviews as a problem for all systems. Inherent in the 
problem are the problems identified and analyzed in sub¬ 
sections one through three of this section. The problem of CM 
over the life-cycle involves who is going to perform CM, who 
will be in charge or manage CM, who will provide resources at 
a given phase of the life-cycle and what is required by 
instructions or regulations depending upon the life-cycle 
phase of the system. 

The research indicated simply that CM is required for the 
entire life-cycle of the system. The type of CM performed 
during the acquisition stage is done by the development or 
production contractor with Government chairmanship of CCBs or 
at least attendance as a voting member on a given CCB. Policy 
should, however, clearly identify both contractor and 
Government involvement and responsibilities in the process. 
This can be done by properly maintaining the addenda to the 
master CM plan as the system progresses through the various 
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phases from acquisition to operation and support. 

As the system is made operable, in some cases the 
Government (in the case of NAWCTSD an ISEO) will perform CM 
exclusively, or both the Government and a support contractor 
will perform CM, or a support contractor will perform CM 
exclusively for the Government. In all of these cases a 
master CM plan with addenda modified and updated at each phase 
of the life-cycle will clarify participating roles and 
responsibilities. 

NAWCTSD sometimes acquires a system for support after it 
was procured by another agency. In these cases CM for the 
system may have been addressed or it may accrue to NAWCTSD to 
develop the system. Depending on the resources available, the 
addenda to the master plan would accommodate starting a CM 
system or assuming responsibility for maintaining a CM system 
status-quo if it existed. CM policy must address all 
possibilities of required CM support as a matter of policy in 
order to clarify roles and responsibilities for all 
individuals within competencies. 

3. Conflicting Regulations and Directives 

This problem is addressed by determining what is required 
and what is recommended. Instructions are, by definition, not 
directives and are thus open to interpretation and some leeway 
in implementation. However, superior instructions carry the 
weight of authority of the superior organization and thus in 
most cases implementing organizations attempt to follow 
instructions as closely as possible. 

In the case of NAWCTSD, the superior organization and 
instruction is NAVAIR and NAVAIRINST 4130.1C respectively. 
Measured against NAVAIRINST 4130.1C there are few if any 
conflicts with DoD instructions and regulations and none with 
existing regulations at NAWCTSD. The author was unable to 
find any statutory requirements with regard to CM. Therefore, 
it is the author's opinion that the instructions implementing 
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both policy and CM at the working level from the Secretary of 
the Navy to NAWCTSD are not in conflict. 

Chapter V identified the fact that NAVAIRINST 4130.1C did 
not indicate the level to which CM was to be performed. DoD 
5000.2 requires only that configuration items be traceable to 
a work breakdown structure. This is not a conflict since DoD 
Instruction 5000.2 can be tailored to individual programs and 
projects. NAVAIRINST 4130.1C does not address every issue 
faced by NAWCTSD in implementing CM across all platforms and 
systems supported by NAWCTSD. This is not a conflict, it 
simply requires that NAWCTSD "fill in the blanks" in order to 
develop a comprehensive CM policy and implementation plan. In 
essence, latitude is allowed in order for subordinate entities 
to fulfill requirements that may not be known to superiors. 
This does not give NAWCTSD free reign to develop policy 
outside the legal purview of the DoD but it does give ample 
room to develop policy that will be successful in 
accomplishing the requirement to implement CM as an Office of 
Primary Responsibility (OPR) under NAVAIR. 

The greatest single potential conflicting in interpreting 
and implementing CM is the interpretation and implementation 
of the Perry Memorandum [Ref. 1]. No other single document 
has such far reaching potential to cause change in the 
acquisition, and by default, the life-cycle support of DoD 
systems. For purposes of analysis by the author, it is only 
clear that change is inevitable. The resulting change will 
affect every aspect of system procurement and life-cycle 
support. Exactly how it will affect it and the time-table are 
unknown. 
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VII. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

NAWCTSD confronts a monumental task in responding to CM 
requirements across the broad spectrum of Services, other 
Government agencies, non-Government agencies, and a huge and 
diverse inventory of training devices and systems. It is 
clear that CM efforts at NAWCTSD can benefit by improving and 
clarifying policy and implementation requirements. NAWCTSD 
can also benefit by improving the management of its CM effort 
to address the differences as well as the common elements of 
CM across the spectrum of systems supported by NAWCTSD. Both 
internal and external customers will benefit if improvements 
are made in policy and policy implementation. 

The instruction governing the implementation of CM at 
NAWCTSD, NAVAIRINST 4130.1C, is comprehensive and empowers 
NAWCTSD to accomplish its CM responsibilities in the most 
efficient manner possible. As an OPR, NAWCTSD is given clear 
directions contained in the list of OPR responsibilities. 
Those responsibilities are the minimum required and thus 
NAWCTSD may add to them as needed in order to accomplish or 
enhance the accomplishment of its CM mission. This thesis 
will recommend additional elements of CM that should be added 
to the list of requirements and will also suggest other 
changes to the present system to enhance its effectiveness. 

B. RECOMMENDATIONS 

To effectively implement CM policy at NAWCTSD it is 
necessary that upper level management commit adequate 
resources to accomplish and demonstrate support of CM policy. 
Competency 1.3.2 in its role of CM management at NAWCTSD must 
effectively communicate policy to all competencies tasked with 
implementing that policy. This thesis identifies essential 
elements of CM policy and addresses issues relevant to 
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implementing that policy. The thesis did not provide a 
written policy. Competency 1.3.2 should modify the existing 
policy based on recommendations from this thesis. The 
resulting written policy should be concise, easy to read and 
easy to understand. It should reference NAVAIRINST 4130.1C as 
the primary superior instruction and, where appropriate for 
clarity, it should reference exact paragraphs or sections in 
that instruction in order to enhance clarity of requirements. 
It should also reference other DoD instructions and military 
standards as needed and identified in the answers to the 
research subsidiary questions. 

The policy should identify core CM tasks to be 
accomplished by NAWCTSD competencies. The accomplishment of 
core CM tasks should be standardized with respect to data 
requirements and procedures. At the same time, the policy 
must address the CM requirements for individual programs. It 
must identify potential differences in implementation of CM 
across the spectrum of supported devices and customers and 
must also account for the implementation of CM by ISEOs 
actually performing engineering modification tasks or 
supporting acquisition programs. 

The roles and responsibilities of every competency tasked 
to perform CM for NAWCTSD acquired and supported devices must 
be clearly established in written policy. Additionally, 
Competency 1.3.2 should address updating CCB charters for 
NAWCTSD acquired and supported devices to clarify the role of 
NAWCTSD versus that of NAVAIR in maintaining CCB control of 
baselines. In order to facilitate the diverse customer and 
device base, it is recommended that Competency 1.3.2 write a 
master configuration management plan. The policy statement 
should describe how the master CM plan can be modified by 
adding addenda to the plan as indicated in NAVAIRINST 4130.1C. 
The addenda can be used to tailor the master CM plan to 
accommodate differences in individual programs. 
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As chair of the TECCB and as an Associate Member of the 
NAVAIR CCB, Competency 1.3.2 has the responsibility to assure 
that all- changes to existing baselines under the control of 
NAWCTSD are properly documented and traceable. Establishment 
of a comprehensive status accounting system that meets the 
needs of all users and customers, internal and external to 
NAWCTSD, must be developed. It is recommended that Competency 
1.3.2 use the expertise of personnel in the Logistics Support 
Competency 3.0 to assist in developing CM policy, implementing 
CM policy, and providing life-cycle support for CM. This 
recommendation is based on the fact that Competency 3.0 was 
the lead competency until approximately November 1994. 
Competency 3.0 also has the lead on the development of the 
configuration status accounting data base. 

It is recommended that the frequency of audits and the 
competencies responsible for performing audits be included in 
the written CM policy statement. 

The final recommendation relative to implementing CM 
policy at NAWCTSD concerns training of key personnel. CM is 
a complex endeavor. It requires knowledge of CM processes and 
procedures as well as goals and limitations. The theoretical 
knowledge is contained in text books and articles, some of 
which are referenced and discussed in this thesis. The 
working and implementation knowledge is contained in technical 
manuals, instructions, and military standards and 
specifications. Personnel required to implement and manage CM 
must be trained in order to perform the necessary functions. 
It is recommended that Competency 1.3.2 establish a CM 
training plan and that specific personnel be targeted to 
receive CM training as needed. 
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C. ANSWERS TO RESEARCH AND SUBSIDIARY QUESTIONS 

1. Research Question 

What should be the essential elements of a Configuration 
Management (CM) policy for NAWCTSD acquisitions and how might 
this policy be implemented? 

FOUR MAJOR ELEMENTS OF CM: 

The question of how the policy might be implemented is 
answered in the subsidiary questions. 

1. Configuration Identification. Selection of the 
documents which identify and define the configuration 
baseline characteristics of an item. 

2. Configuration Control. Controlling changes to the 
configuration and its identification documents. 

3. Configuration Status Accounting. Recording and 
reporting the implementation of changes to the 
configuration and its identification documents. 

4. Configuration Audit. Checking an item for 
compliance with the configuration identification. 


2. Subsidiary Questions 

What are the essential elements of CM policy and what are 
the requirements established by DoN, DoD, and other Government 
agencies? 

The following answers are summary answers. Detailed 
answers are available in previous chapters. 

Essential elements include CM plans, configuration 
identification, change control, configuration status 
accounting, technical documentation management, physical and 
functional audits, and that CM be performed for the life-cycle 
of a configuration item. 

NAVAIRINST 4130.1C requires the following seven CM 
functions (discussed in detail in the body of the thesis) of 
NAWCTSD because NAWCTSD is an Office of Primary Responsibility 
(OPR) : 
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1. provide CM of assigned CIs throughout their life 
cycle; 

2. - prepare and maintain CM plans for assigned Cis; 
obtaining approval of these plans, and assuring proper 
implementation of NAVAIRINST 4130.1C; 

3. manage and provide direction for the staffing of all 
engineering change proposals, RAMECs, and requests for 
major and critical deviations and waivers from initiation 
until submittal to a CCB; 

4. implement CCB directed actions; 

5. maintain the status of implementing actions for 
approved engineering changes, deviations, and waivers; 

6. conduct audits, establish baselines; and 

7. establish and maintain an adequate configuration 
status accounting system. 

NAVAIRINST 4130.1C requires that NAWCTSD develop a CM 
master plan since it is responsible for more than one 
configuration item. The master plan can be tailored to suite 
specific programs (configuration items) by the addition of 
addenda to the master plan. 

DoDI 5000.2 states that all configuration items be 
traceable to an element of a work breakdown structure. 
NAVAIRINST 4130.1C does not mention this requirement. It is 
the recommendation of this thesis that this be established as 
a matter of policy. Other details of requirements from DoDI 
5000.2 are included in the body of the thesis. 

What are the basic components of CM policies that exist 
for similar Government organizations and industry firms? 

Research failed to identify other Government agencies 
that paralleled NAWCTSD in function. Other agencies do not 
have the same large customer base, nor are they responsible 
for such a large and diverse number of complex configuration 
items. NAWCTSD appears to be unique in that respect. Other 
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agencies were studied, however, to determine their approach to 
implementing CM and their policy. 

The Army Tactical Missile System (ATACMS) uses the 
contractor to perform CM on developing and delivered systems. 
Army involvement is to chair the CCB and to be a member of 
CCBs as necessary to assure Government control of changes. 
Contractual documents reflect the Army Acquisition Executives 
policy that functional specifications and simplified 
statements of work be implemented in order to streamline the 
process and reduce cost. 

NASA uses contractors exclusively to perform CM for 
hardware and software. Their involvement is the same as the 
Army. They chair the CCBs or are members of CCBs for every 
element of the shuttle program. 

Loral, under contract to NASA for Shuttle software 
development has achieved a high level of process maturity. CM 
is a part of every process at Loral. The process of CM itself 
is under CM. It is a mind set, automatically part of all 
processes, at every level of the company. 

What are the significant problems and issues associated 
with establishing a CM policy that is unique to NAWCTSD and 
how might these problems and issues be solved? 

It is important to determine exactly which competency is 
"in charge" of CM and which competencies are required to 
implement CM on their programs and systems. Competency 1.3.2 
is tasked with developing and managing CM policy at NAWCTSD. 
Many other competencies are responsible for implementing 
policy. The policy developed for NAWCTSD should require that 
a master CM plan be written and that implementing competencies 
modify that plan with attached addenda to make the plan 
specific to their needs and to the needs of their customers. 

Problems with implementation are the large customer base, 
the large size of the inventory, and the complex 
infrastructure represented by the various competencies. The 
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CM policy must address these issues by clarifying the roles 
and responsibilities of competencies required to implement CM. 
Acquisition documents must reflect CM requirements and provide 
data requirements to complement the NAWCTSD status accounting 
system. 

Training must be developed for all personnel required to 
implement CM in order to assure that personnel are technically 
competent and to improve standardization of methodology. 

The level to which CM is to be implemented is answered by 
the requirement contained in DoDI 5000.2 that configuration 
items be traceable to the work breakdown structure. It is the 
recommendation of this author that CM be performed to at least 
level three (the summary level WBS). Further system 
decomposition is dependent upon individual system and program 
requirements and resources. 

CM during the acquisition phase begins at the end of 
concept exploration and definition. It is to be practiced on 
a continuum during all life-cycle phases of the system. CM 
plans are to be modified and updated at all major system 
milestones. CM on fielded systems should simply be a 
continuum of CM planning from the acquisition phases. If not, 
CM policy must dictate that necessary CM be performed in 
accordance with NAVAIRINST 4130.1C based on available 
resources and specific system requirements. For system 
acquired by other agencies and turned over to NAWCTSD for 
support under the Cognizance Symbol 2"0" umbrella, CM must be 
practiced the same as for all other systems within given 
resource constraints. 

This thesis found no major conflicts between DoD, DoN, 
NAVAIR, and NAWCTSD instructions. Interpretation of those 
instructions is and likely always will be contentious. 
Recognition of NAVAIRINST 4130.1C as the instruction to be 
used to implement CM and CM policy at NAWCTSD will assure that 
there is no conflict. NAVAIRINST 4130.1C includes minimum 


87 



instructions and therefore additional elements can be added to 
the policy to enhance that required by NAVAIR. 

The advent of the Perry Memorandum [Ref. 1] has caused a 
great deal of flux in the implementation of military standards 
and specifications. The whole of acquisition is changing to 
streamline the process. CM is part of the impacted processes. 
MIL-STD-973 was to be the answer to standardizing CM and CM 
processes. The Perry Memorandum [Ref. 1] will likely affect 
implementation of MIL-STD-973 in a negative way. 

D. AREAS FOR FURTHER RESEARCH 

The NASA whole systems approach to CM is worthy of 
additional study. NASA's Ames Research Center has implemented 
a CM system that employs virtually the same process on both 
hardware and software CM. 
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APPENDIX A 


DENDRITIC ANALYSIS 




Dendritic Approach to Determining Essential Elements of CM Policy for NAWCTSD 
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APPENDIX B 


GLOSSARY OF ACRONYMS 


AAE 
ACAT I 
AC I 

ATACMS 

ATE 

CALS 

CASE 

CCB 

CDRL 

CE&D 

Cl 

CM 

CMIS 

CSA 

DEMVAL 

DoD 

DoDI 

DON 

DPRO 

ECP 

EMD 

FCI 

HCM 

I CD 

ICWG 

IEEE 

ILSM 

IRN 


Army Acquisition Executive 
Acquisition Category 1 

Allocated Configuration Identification 
Army Tactical Missile System 
Automatic Test Equipment 

Computer-aided Acquisition and Logistics Support 

Computer Aided Software Engineering 

Change Control Board 

Contract Deliverable 

Concept Exploration and Definition 

Configuration Item 

Configuration Management 

Configuration Management Information System 

Configuration Status Accounting 

Demonstration and Validation 

Department of Defense 

Department of Defense Instruction 

Department of the Navy 

Defense Plant Representative Office 

Engineering Change Proposal 

Engineering and Manufacturing Development 

Functional Configuration Identification 

Hardware Configuration Management 

Interface Control Drawing 

Interface Control Working Group 

International Electical and Electronics Engineering 
Integrated Logistics Support Manager 
Interface Revision Notice 
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ISEO 

LCS 

MOA 

MOE 

MOP 

NASA 

NAWCTSD 

NDI 

NOR 

NPS 

NSTS 

PCI 

PO&M 

O&M, N 

OPR 

PCA 

PD 

PJM 

PM 

RAMEC 

RFP 

SCM 

SCN 

SCCB 

SOW 

SSP 

STE 

SWFPAC 

TECCB 

TECP 

WBS 


In-Service Engineering Office (ISEO) 

Life Cycle Support 
Memorandum of Agreement 
Measure of Effectiveness 
Measure of Performance 

National Aeronautics and Space Administration 

Naval Air Warfare Center Training Systems Division 

Nondevelopmental Item 

Notice of Revision 

Naval Postgraduate School 

National Space Transportation System 

Physical Configuration Item 

Operation and Maintenance 

Operation and Maintenance, Navy 

Office of Primary Responsibility 

Physical Configuration Audit 

Project Director 

Project Manager 

Project Manager 

Rapid Action Minor Engineering Change 

Request for Proposal 

Software Configuration Management 

Software Change Notice 

Software Change Control Board 

Statement of Work 

Space Shuttle Program 

Software Test Equipment 

Surface Warfare Pacific 

Trainer Engineering Change Control Board 
Trainer Engineering Change Proposal 
Work Breakdown Structure 
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APPENDIX C 


DEFINITION OF TERMS 

1 . ALLOCATED BASELINE. The initially approved 
documentation describing an item's functional and interface 
characterisitics that are allocated from those of a higher- 
level configuration item, interface requirements with 
interfacing configuration items, additional design 
constraints, and the verification required to demonstrate the 
achievement of those specified functional and interface 
characteristics. 

2. BASELINE. A configuration identification document or 
a set of documents formally designated and fixed at a specific 
time during a configuration item's (Cl's) life cycle. 
Baselines plus approved changes from those baselines, 
constitute the current configuration identification. 

3. Cognizant Field Activity (CFA) . The Navy field 
activity which has been assigned the responsibility and 
delegated the authority by NAVAIRSYSCOM HQ under reference (q) 
to perform all or portions of the in-service functions, 
including procurement support, for specific service equipment. 

4. Cognizance Symbol 2"0" Equipment . Those training 
device end items that have been specifically developed, 
procured, cataloged, distributed, and supported by 
NAVAIRWARCENTRASYSDIV to fulfill a training requirement. It 
also includes training devices procured outside of the NAWCTSD 
and subsequently transferred by mutual agreement to NAWCTSD 
for inventory management, maintenance, and support. 

5. Configuration . The functional and physical 
characteristics of existing or planned hardware, firmware, 
software, or a combination thereof as set forth in technical 
documentation and ultimately achieved in a product. 
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6- Configuration Baseline . Configuration documentation 
formally designated by the Government at a specific time 
during - a configuration item's (Cl's) life cycle. 
Configuration baselines, plus approved changes from those 
baselines, constitute the current approved configuration 
documentation. There are three formally designated 
configuration baselines in the life cycle of a configuration 
item, namely the functional, allocated, and product baselines. 

7 - Configuration Control . The systematic proposal, 
justification, evaluation, coordination, approval or 
disapproval of proposed changes, and the implementation of all 
approved changes in the configuration of a Cl after 
establishment of the configuration baseline(s) for the Cl. 

8. Configuration Control Board (CCB) . A board composed 
of technical and administrative representatives who recommend 
approval or disapproval of proposed engineering changes to a 
Cl's current approved configuration documentation. The board 
also recommends approval or disapproval of proposed waivers 
and deviations from a Cl's current approved configuration 
documentation. 

9. Configuration Identification . Configuration 
identification includes the selection of CIs; the 
determination of the types of configuration documentation 
required for each Cl; the issuance of numbers and other 
identifiers affixed to the CIs and to the technical 
documentation that defines the Cl's configuration, including 
internal and external interfaces; the release of CIs and their 
associated configuration documentation,- and the establishment 
of configuration baselines for CIs. 

10 • Configuration Item (Cl) . A configuration item is an 
aggregation of hardware or software that satisfies an end use 
function, and is designated by the Government for separate 
configuration management. 

11. Configuration Management (CM). 
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a. As Applied to configuration items a discipline 
applying technical and administrative direction and 
surveillance over the life-cycle of items to: 

(1) Identify and document the functional and 
physical characteristics of configuration items. 

(2) Control changes to configuration items and 
their related documentation. 

(3) Record and report information needed to 
manage configuration items effectively, including the status 
of proposed changes and implementation status of approved 
changes. 

(4) Audit configuration items to verify 
conformance to specifications, drawings, interface control 
documents, and other tasking or contract requirements. 

b. As applied to digital data files the 
application of selected configuration identification and 
configuration status accounting principles to: 

(1) Uniquely identify the digital data files 
including versions of the files and their status (e.g. 
working, released, submitted, approved). 

(2) Record and report information needed to 
manage the data files effectively, including the status of 
updated versions of files. 

12. Configuration Management Support System (CMSS) . A 
NAWCTSD remote access computerized data file and processor 
utilized for configuration status accounting of changes to COG 
2"0" training devices/systems. 

13. Configuration Status Accounting (CSA) . The 
recording and reporting of information needed to manage 
configuration effectively, including: 

a. A record of the approved configuration documentation 
and identification numbers. 

b. The status of proposed changes, deviations, and 
waivers to the configuration. 
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c. The implementation status of approved changes. 

d. The configuration of all units of the configuration 
item in'the operational inventory. 

14. Data . Recorded information, regardless of medium or 
characteristics, of any nature, including administrative, 
managerial, financial, and technical. 

15. Design Change . See "engineering change". 

16• Digital Technical Data. A primary thrust of the 
Computer-Aided Acquisition and Logistics Support (CALS) effort 
is the automation and integration of the generation, delivery, 
and use of weapon system technical data over the weapon 
system's life cycle. This technical data includes: 

a. The part descriptions, product specifications, 
and standards that the initial designer draws upon. 

b. The engineering drawings and product data used 
in design and manufacturing, including product descriptions 
and specifications data used for design reviews. 

c. The information needed to guide the people who 
operate the system in the field, or who support and maintain 
it at all echelons of the logistic support structure. 

d. The materials needed to train new operators, 
maintainers and other technicians, and the information needed 
for re-procurement, remanufacturing, modification, and 
feedback to industry for future design. 

(CALS has published technical standards which enable either 
delivery of this information in digital form or government 
access to contractor-maintained technical data bases.) 

IV. Engineering Change . A change to the current 
approved configuration documentation of a configuration item 
at any point in the life cycle of the item. 

18. Engineering Change Priorities . The priority 
(emergency, urgent, routine) assigned to a Class I engineering 
change which determines the relative speed at which the 
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Engineering Change Proposal is to be reviewed, evaluated, 
and,if approved, ordered and implemented. 

19 .- Engineering Change Proposal (ECP) . A proposed 
engineering change and the documentation by which the change 
is described, justified, and submitted to the Government for 
approval or disapproval. 

20. Engineering Change Proposal Types . A term covering 
the subdivision of Class I Engineering Change Proposals on the 
basis of the completeness of the available information 
delineating and defining the engineering change. They will be 
identified as preliminary or formal. 

21. Functional Baseline (FBL) . The initially approved 
documentation describing a system's or item's functional, 
interoperability, and interface characteristics and the 
verification required to demonstrate the achievement of those 
specified characteristics. 

22. Functional Characteristics . Quantitative 
performance parameters and design constraints, including 
operational and logistic parameters and their respective 
tolerances. Functional characteristics include all 
performance parameters, such as range, speed, lethality, 
reliability, maintainability, and safety. 

23. Functional Configuration Audit (FCA) . The formal 
examination of functional characteristics of a configuration 
item, prior to acceptance, to verify that the item has 
achieved the requirements specified in its functional and 
allocated configuration documentation. 

24. Government Furnished Equipment (GFE)/Government 
Furnished Property (GFP) . Property in the possession or 
acquired by the Government and subsequently delivered or 
otherwise made available to the contractor. 

25. In-Service Engineer Office _ (ISEO) . A 

NAVAIRWARCENTRASYSDIV field office staffed with specialists 
who provide Cognizance Symbol 2"0" training device/system 
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technical, engineering, and logistics support through direct 
responses to equipment users/custodians and through 
performance of assigned NAWCTSD device life cycle support 
program tasks and functions. (Reference (e) applies.) 

26. Local Change Control Board (LCCB) . An "on-site" 
modification review committee, chaired by the ISEO manager and 
consisting of representatives from the ISEO and 
users/custodians, established to exercise configuration 
control of trainer software on a local basis. User/custodian 
representation on the committee will be requested by the 
chairman. 

27. Office of Primary Responsibility (OPR) . As used in 
this document, includes the project manager or acquisition 
manager, as applicable. 

28. Physical Characteristics . Quantitative and 
qualitative expressions of material features, such as 
composition, dimensions, finishes, form, fit, and their 
respective tolerances. 

29. Physical Configuration Audit (PCA) . The formal 
examination of the "as-built" configuration of a Cl against 
its technical documentation to establish or verify the Cl's 
product baseline. 

30. Product Baseline (PBL) . The initially approved 
documentation describing all of the necessary functional and 
physical characteristics of the configuration item and the 
selected functional and physical characteristics designated 
for production acceptance testing and tests necessary for 
support of the configuration item. In addition to this 
documentation, the product baseline of a configuration item 
may consist of the actual equipment and software. 

31. Software . See "Computer Software" in DOD-STD-2167. 

32. Specification . See MIL-STD-961. 

33. Specification Change Notice (SCN) . A document used 
to propose, transmit, and record changes to a specification. 
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34. System . See MIL-STD-280. 

35. Tailoring. The process by which individual 
requirements (sections, paragraphs, or sentences) of a 
specification, standard, or data requirement are evaluated to 
determine the extent to which they are most suitable for a 
specific system, and the deletion of some requirements to 
ensure that each achieves an optimal balance between 
operational needs and cost. 

36. TECD No. 001 . TECD No. 001 is a record purpose 
baseline document that provides a configuration baseline 
summary for each new training device or system. In specific 
cases of major modification, the TECD Baseline Document may be 
assigned a number other than 001. 

37. Technical Data . Technical data is recorded 
information (regardless of the form or method of recording) of 
a scientific or technical nature (including computer software 
documentation) relating to supplies procured by an agency. 
Technical data does not include computer software or 
financial, administrative, cost or pricing, or management data 
or other information incidental to contract administration. 

a. Technical data is required to define and document an 
engineering design or product configuration (sufficient to 
allow duplication of the original items) and is used to 
support production, engineering, and logistics activities. 

b. A technical data package should include all 
engineering drawings, associated lists, process descriptions, 
and other documents which define the physical geometry, 
material composition, performance characteristics, 
manufacture, assembly, and acceptance test procedures. 

c. Technical data which provides instructions for the 
installation, operation, maintenance, training, and support of 
a system or equipment can be formatted into a technical 
manual. 

(1) A technical manual normally includes operation 
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and maintenance instructions, parts lists or parts breakdown, 
and related technical information or procedures exclusive of 
administrative procedures. 

(2) This data may be presented in any form (e.g., 
hard copy, audio and visual displays, magnetic tape, disks, or 
other electronic devices). 

(3) Technical orders that meet the criteria of this 
definition may also be classified as technical manuals (Title 
10, United States Code, Section 2302, "Definitions). 

38. Technical Data Package . See "Technical Data". 

39. Technical Documentation . See "Technical Data". 

40. Technical Reviews . A series of system engineering 
activities by which the technical progress on a project is 
assessed relative to its technical or contractual 
requirements. The reviews are conducted at logical transition 
points in the development effort to identify and correct 
problems resulting from the work completed thus far before the 
problems can disrupt or delay the technical progress. The 
reviews provide a method for the contractor and Government to 
determine that the development of a configuration item and its 
documentation have met contract requirements. 

41. Trainer Engineering Chancre Proposal (TECP) . A 
proposed engineering change and the documentation by which a 
training device/system unique change is described, justified, 
and submitted to the Government for approval or disapproval. 
(Reference (d), paragraph 3.38) 

42. Training Device/System . All types of maintenance 
and operator training hardware, devices, audio-visual training 
aids, equipment, systems, and related software which: 

a. Are used to train maintenance and operator personnel 
by depicting, simulating, or portraying the operational or 
maintenance characteristics of an item or facility. 

b. Are kept consistent in design, construction, and 
configuration with such items in order to provide required 
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training capability. 

43. Training Equipment Change Control Board (TECCB) . 
The NAVA-IRWARCENTRASYSDIV vehicle for coordination of COG 2 M 0" 
training device/system configuration related matters. Results 
of board actions represent the official NAWCTSD position 
regarding configuration matters. The board composition, 
organization, jurisdiction, and operating procedures are in 
Appendix D of NAWCTWDINST 4130._M. 

44. Training Equipment Change Directive (TECD) . A 
unique technical directive issued by the NAVAIRWARCENTRASYSDIV 
which is used to direct the accomplishment and recording of 
modifications to cognizance symbol 2"0" training 
devices/systems and companion software system items, prepared 
using the format in NAWCTSDINST 4130._M, Appendix J. 

45. Training Equipment Change Request (TECR), NTSC 
4720/2 . A document which initially addresses a requirement 
for a configuration change to a training device/system. TECRs 
are normally submitted by training device/system user 
activities/ custodians, or by NAWCTSD ISEOs. (Reference (j) 
applies.) 

46. Training Equipment Model Manager (TEMM) . For 
surface trainers only, this is a NAVEDTRACOM activity, 
designated by the Chief of Naval Education and Training that 
is responsible for reviewing weapon system/platform changes 
for applicability and specific training systems impact 
assessment. 

47. Validation . The process by which the preparing 
activity tests a technical directive for accuracy and 
adequacy. 

48. Version . An identified and documented body of 
software. Modifications to a version of software (resulting 
in a new version) require configuration management actions by 
either the contractor, the Government, or both. 

49. Waiver . A written authorization to accept an item, 
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which during manufacture, or after having been submitted for 
Government inspection or acceptance, is found to depart from 
specified requirements, but nevertheless is considered 
suitable for use "as is" or after repair by an approved 
method. 

50. Weapon Svstem/Platform Change . An Engineering 
Change Proposal (ECP), Ordnance Alteration (ORDALT), Ship 
Alteration (SHIPALT), Airframe Change (AFC), or similar change 
affecting an operational system or its logistic support. Such 
changes may or may not address training systems used in 
support of such operational equipment. 

51. Work Breakdown Structure (WBS) . See MIL-STD-881. 

52. Work Breakdown Structure Element . See MIL-STD-881. 
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1.0 INTRODUCTION 


1.1 PURPOSE 

This document defines the requirements, responsibilities, and procedures for all Space 
Shuttle Program elements/projects in the application of configuration management on 
the Space Shuttle Program. 

All program level configuration management requirements for the Space Shuttle 
Program are contained herein. In the event of conflicting statements regarding configu¬ 
ration management requirements between this volume and any other SSP document, 
the requirement of this document shall take precedence. However, if a Program Direc¬ 
tive has been subsequently issued by the Director, Space Shuttle Operations, which 
affects the statement(s) in question, the Program Directive shall take precedence. 

1.2 SCOPE 

This document has been jointly developed by the NASA Centers, and represents a 
careful application of the experience gained in previous NASA, military, and commercial 
space and aircraft programs. The requirements, responsibilities, and procedures 
defined herein are applicable to all organizations and personnel involved in the Space 
Shuttle program. This volume also defines those requirements, responsibilities, and 
procedures applicable to contractor activities necessary to achieving total program con¬ 
figuration management objectives. 
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3.0 CONFIGURATION IDENTIFICATION 


Configuration identification determines the manner in which the requirements for and 
configuration of all program hardware/software is described and the documentation of 
these descriptions. Configuration identification for the SSP shall be accomplished 
through the development of formal documentation, defined herein, which will describe 
the baseline to be used for planning purposes and for control and accounting of future 
changes. Refer to Appendix E for requirements and guidance in respect to Contract 
End Item (CEI) specifications, drawings and associated lists selection, identification and 
preparation. Two general types of baselines shall be addressed, i.e., “NASA baseline" 
and “design activity/contractor baseline." These requirements will be imposed upon the 
appropriate design activity/contractor by the responsible NASA project office/organiza¬ 
tion. 


3.1 NASA BASELINE 

3.1.1 NASA Requirements Baseline 

This baseline shall be defined by the documentation that describes the current NASA 
approved technical and management requirements (reference Figure 3-1). The NASA 
requirements shall be described and controlled in program and project documentation 
as follows: 

Area of Responsibility Management Responsibility 

Program Requirements Director, Space Shuttle Operations, 

Manager, Launch Integration, KSC 

Project Requirements Project Managers 

Initially, the NASA baseline consists primarily of program management and system per* 
formance requirements. As the development effort matures, the end item requirements 
(Orbiter, External Tank, etc.) are defined, baselined, and controlled. Each of the lower 
level baseline documents are compatible with the requirements of the higher level base¬ 
line documents and shall further define, as necessary, those applicable requirements. 
The baselines are expanded during the development effort as requirements mature. 

The amount of information to be contained in the baselines is determined on an indi¬ 
vidual basis. 

At the appropriate time, a design freeze of the Shuttle System configurations is estab¬ 
lished to eliminate unnecessary changes and to preserve the Shuttle System 
configuration which was verified through the development and Orbital Flight Test 
phases of the program. At this time the NASA baseline is expanded to include the pro¬ 
duction drawings and a complete description of the product physical and functional 
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configuration. Change approval authority for Class I changes (reference Paragraph 
4.1) to the baseline is elevated to the SSP and selectively delegated to the Projects. 
Changes approved by the Projects are subsequently reviewed by the Space Shuttle 
Program for system implications. 

The specifications for the Space Shuttle System and its elements shall consist of the 
documents shown in Figure 3-2. 

The preceding describes a “progressive” baseline that is fundamental to the Space 
Shuttle Program configuration management approach. A graphical representation of 
this “progressive" baseline is shown in Figure 3-3. 

The drawings and documents reflected in the Space Shuttle Top Assembly Drawing 
Tree (Figure 3-4) constitute the Space Shuttle Program baseline requirements for 
design and construction of the Shuttle System. These requirements shall be imple¬ 
mented by all affected Shuttle System design and Operation and Maintenance (O&M) 
activities. Implementation and change control responsibilities are defined in Appendix 
Q. 

Program freeze points are established at specific intervals for each flight. The freeze 
points are defined in NSTS 07700, Volume III, Flight Definition and Requirements Direc¬ 
tive. 

3.1.2 NASA Acceptance Baseline 

The as-built configuration of the flight hardware/software is documented by the 
accepting Space Shuttle Program/project element at the acceptance review. The NASA 
Space Shuttle Program control of the flight hardware/software commences with the 
acceptance review, and changes subsequent to acceptance (DD-250) of hardware/soft¬ 
ware will require authorization by the Space Shuttle PRCB. Configuration control of 
accepted flight hardware/software, including delegated authority, is defined in Para¬ 
graph 4.2 and subparagraphs. 

3.1.3 (Deleted) 

3.1.4 Space Shuttle Program Baseline 

The SSP baseline documentation shall contain program requirements, Space Shuttle 
management requirements, system technical requirements, descriptive documentation, 
and indentured parts listings and other identification documents describing the configu¬ 
ration of all Space Shuttle flight hardware/software. These baseline requirements may 
be apportioned to the program elements/projects, by the Director, Space Shuttle Opera¬ 
tions. The documentation shall contain the following types of data: 
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a. Program definition 

b. Program characteristics 

c. Program interface requirements 

d. Program verification requirements 

e. System responsibility allocations 

f. System schedules 

g. System budget and cost allocations 

h. Management system requirements 

i. Information systems requirements 

j. System design and performance requirements 

k. System interface requirements, excluding interfaces to be controlled by a single 
project office 

l. System verification (acceptance, certification) requirements 

m. Standard design, construction, assembly and installation requirements appli¬ 
cable to the total system 

n. Other applicable allocated requirements 

o. Training requirements 

p. Acceptance baseline configuration descriptions and indentured parts listings for 
flight hardware/software that has had an acceptance review 

3.1.5 Project Baseline 

The Project baseline documentation shall contain specific requirements applicable to 
the particular project; e.g., Solid Rocket Booster (SRB), Orbiter/GFE, Space Shuttle 
Main Engine (SSME), etc. This documentation shall contain the following types of 
information: 

a. Space Shuttle Program requirements 

b. Design and performance requirements 

c. Interface requirements 

d. Verification requirements 
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e. Design, construction, assembly and installation standards and specifications 

f. Training requirements 

g. Design concepts, approaches, and solutions at the appropriate time 

h. Product configuration descriptions at the appropriate time 

3.1.6 Space Shuttle Program Definition and Requirements Baseline 
Documentation 

The SSP baseline is included in, attached to, or referenced from NSTS 07700, Volumes 
I through XVIII, Space Shuttle Program Definition and Requirements. The Space 
Shuttle Program Definition and Requirements baseline documentation is identified for 
reference in the foreword to this document. The content of each volume is described in 
NSTS 07700, Volume I, Program Description and Requirements Baseline. All SSP doc¬ 
umentation will be baselined and controlled in accordance with the requirements and 
procedures contained in this document. 

3-1.7 Preparation, Coordination, and Processing of Baseline Documents 

An OPR will be assigned for each SSP baseline document. The OPR will manage the 
preparation and coordination of the requirements to be included in its assigned volumes 
and, as necessary coordinate drafts up to and including a final draft of the volume to be 
recommended for baselining. This final draft shall be submitted for baselining via a 
SSP Change Request (CR). Detailed requirements and procedures for preparing, coor¬ 
dinating, and processing SSP baseline documents are provided in Paragraph 4.4.3 and 
Appendix C of this volume. Specific requirements and procedures for preparing, coordi¬ 
nating, and baselining SSP Interface Control Documents (ICDs) are provided in 
Paragraph 3.1.8 and Appendix D of this volume. 

3.1.8 Interface Control Documents 

ICDs shall be used to control interfaces between two or more participating contractors 
and government agencies. Authority for control of these documents is as follows: 

a. SSP Interfaces which depict hardware/software interfaces between Projects 
shall be controlled by the Director, Space Shuttle Operations. Interfaces 
between Space Shuttle flight elements as approved by the SSP for imple¬ 
mentation in the Shuttle Avionics Integration Laboratory (SAIL) shall be 
documented in addenda to corresponding flight ICDs. SAIL ICD addenda shall 
be controlled by the SAIL Configuration Control Panel (CCP) to the extent spe¬ 
cified in Paragraph 4.3.3.2.I. In addition, processing of Payload ICDs which 
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4.0 CONFIGURATION CHANGE CONTROL 


After a baseline is established, it is essential that effective, positive control be estab¬ 
lished to preclude any unauthorized changes to that baseline. There must be 
procedures to insure that each proposed change to the baseline is completely 
described (including impacts); is thoroughly coordinated, reviewed, and evaluated; and 
is authorized and implemented in an approved manner. Procedures also must insure 
that changes to a baseline are not accepted or implemented that have not been pro¬ 
cessed in this prescribed manner. 

Control of the Space Shuttle requirements and acceptance baselines and changes 
thereto is to be through the use of Configuration Control Boards (CCBs) and the appli¬ 
cable baseline documentation as defined in Paragraph 3.0. The various configuration 
control levels for the Space Shuttle Program are depicted in Figure 4-1. 

4.1 CHANGE CLASSIFICATION 

All changes shall be classified as either “Class I" or “Class II". All “Class I” changes 
must receive NASA approval prior to implementation. “Class II" changes shall be dis- 
positioned by the contractor’s Change Control System and do not require NASA 
approval. The NASA shall concur on the assigned classification of each change. 

After implementation of the design freeze all subsequent Shuttle System production 
hardware/software shall be built in accordance with the design freeze configuration 
baseline except for changes or waivers specifically authorized as defined herein. Pro¬ 
posed changes to the design freeze baseline shall be classified as Class I or Class II in 
accordance with the following criteria. 

4.1.1 Class I Change 

Changes shall be classified as Class I according to the criteria in Paragraphs 4.1.1.1 
and 4.1.1.2 below. For each program element 4.1.1.1 shall apply before and 4.1.1.2 
shall apply after the design freeze is established. The design freeze shall be estab¬ 
lished for the following hardware/software: 

a. Orbiter - all flight and production 

b. SSME - all flight and production 

c. External Tank - all lightweight tanks 

d. Solid Rocket Booster - all flight and production 

e. Redesigned Solid Rocket Motor - all flight and production 

f. (Deleted) 
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g. Flight Support Equipment - standard crew equipment 

h. Orbiter Primary Avionics Software Version 19 and Subs 

i. Orbiter Backup Flight Software Version 12 and Subs 

j. KSC Launch Processing System (LPS), Checkout, Control, and Monitoring 
Subsystem (CCMS), and interfacing GSE software 

k. Payload checkout and launch software 

After the design freeze is established all changes meeting the criteria of Paragraph 
4.1.1.2 shall require, as a minimum, disposition by the appropriate Project CCB. The 
Project CCBs are authorized to approve changes which do not affect the criteria of 
Paragraph 4.3.2.1 and which are: 

a. Make work/make safe (required for proper fit or function or to eliminate an 
unacceptable safety hazard) 

b. Mission unique (required to configure system for a specific mission) 

c. High payback (results in significant net cost savings, performance increases, or 
turnaround time reductions) 

d. Necessary to add a new capability to the Shuttle System to meet an approved 
mission requirement 

4.1.1.1 Pre-Design Freeze 

Before the design freeze is established for a system element, a change shall be classi¬ 
fied as “Class I" when any of the following are affected: 

a. Requirements contained in the NASA baseline 

b. Contract provisions 

c. Configuration of hardware/software accepted by NASA including test articles 
intended for major integrated tests 

d. The following documentation for a particular configuration of hardware after that 
configuration has been certified: 

1. Engineering drawings 

2. Engineering materials and process specifications 

3. Engineering acceptance test requirements 

4. Certification/verification requirements 
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4.1 .1.2 Post-Design Freeze 

After the design freeze is established a change to flight hardware/software shall be 
classified as “Class I" when any of the following are affected: 

a. Requirements contained in the formal NASA Space Shuttle Program or Project 
baseline documentation 

b. Space Shuttle Program or Project schedule milestones 

c. Contract cost 

d. Contract provisions 

e. Configuration of hardware/software accepted by NASA including test articles 
intended for major ground test (reference Paragraph 4.2) 

f. Government furnished hardware 

g. Interchangeability (as defined in Paragraph 4.4.13.5) with the design freeze 
configuration baseline of components or assemblies of production hardware/ 
software not yet accepted by NASA 

h. Crew procedures or training 

i. Flight planning 

j. Mission Control Center hardware/software 

k. Qualification/certification status 

l. GSE, facilities or trainers 

m. Requirements and procedures defined in NSTS 08171, Operations and Mainte¬ 
nance Requirements and Specifications Document (OMRSD) or Operations 
and Maintenance Instructions (OMIs) 

n. Change in procurement source of any item at any level defined by source con¬ 
trol drawings 

o. Critical process per NHB 5300.4 (1D-2) 

p. Functional or performance characteristics different from that previously docu¬ 
mented or demonstrated in actual operations 

4.1.2 Class II Change 

Any change which does not fall within the Class I definition shall be designated as 
Class II. 
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4.2 CONFIGURATION CONTROL OF ACCEPTED FLIGHT HARDWARE/SOFTWARE 

To facilitate synchronization of the Space Shuttle System configuration among the var¬ 
ious program elements/projects and to assure a coordinated, timely reaction of all 
program elements/projects to necessary changes to the configuration of flight hardware/ 
software after NASA acceptance (DD-250), all configuration changes and requests for 
performance of non-standard work will require authorization by the Space Shuttle Pro¬ 
gram or, where applicable, the delegated project. This authorization will be obtained 
prior to issuance of work authorization at the using site. The mechanisms for disposi- 
tioning these changes are the Space Shuttle PRCB, Special Daily Space Shuttle PRCB 
(reference Paragraph 4.4.13.6), or the appropriate Project CCB. Changes that do not 
meet the criteria of Paragraph 4.4.13.6, such as drawing corrections, clarifications, 
addition of true alternate parts, and non—mandatory flow enhancement changes (which 
relax assembly requirements but meet SSP requirements) can be dispositioned by the 
Project CCB. Emergency changes to accepted flight hardware/software may be imple¬ 
mented in accordance with Paragraph 4.4.3.2.1. 

Configuration changes which violate any of the SSP criteria defined below (a - g) must 
be forwarded to the Space Shuttle Program for disposition. Other configuration change 
approvals are delegated to the projects as defined in Paragraphs 4.2.1, 4.2.2 4 2 3 and 
4.2.4. 

a. Impact performance, safety, resources or major milestone schedules. 

b. Affect SSP interface control document requirements. 

c. Cannibalization of flight hardware. 

d. Changes associated with resolution of major anomalies or incidents, or 
changes which are deemed significant to the program. 

e. Engineering or hardware required to incorporate the change will not meet the 
specified site need date. 

f. A flight hardware change that impacts any level of assembly interchangeability 
(Paragraph 4.4.13.5). 

g. Impacts other projects (except as delegated in Paragraphs 4.2.1 and 4.2.4) or 
program elements, i.e., mission operations, flight crew operations, flight soft¬ 
ware, Launch Commit Criteria (LCC), etc. 

Requests for non-standard work performed at the launch site which violate the criteria 
defined in Paragraph 4.4.13.7a, must be forwarded to the Space Shuttle Program for 
disposition. 
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5.0 CONFIGURATION ACCOUNTING 


Configuration accounting is the element of Configuration Management (CM) that pro¬ 
vides the essential records and reporting of precise configuration data for all Space 
Shuttle hardware/software. The primary objectives of configuration accounting are as 
follows: 

a. To maintain and disseminate the current configuration data of each program/ 
project element 

b. To maintain correlation among the configuration data for various equipment, 
software, and support elements 

c. To maintain current and accurate records of the status of changes completed 
and in process 

The configuration accounting system shall include the task of maintaining, storing, and 
correlating configuration documentation of all hardware/software. This includes activi¬ 
ties required to receive inputs from the design activity release desk (as-designed), 
quality control (as-built), and other sources (i.e., as-tested, as-qualified, as-delivered, 
as-flown, etc.); and to compare, summarize, and produce configuration summaries, dif¬ 
ferences, and other comparison data as may be of value to various program 
organizations. 


5.1 ICD CROSS-REFERENCE SYSTEM 

Each design activity/contractor shall maintain a system that indicates which engineering 
drawings are affected by Space Shuttle Program and project ICDs. This system will 
allow the designer or other affected parties to determine which drawings and/or ICDs 
may be affected by a proposed change. 


5.2 SPACE SHUTTLE INTEGRATED PROGRAM ICD STATUS 

The Space Shuttle Program shall utilize the NASA Open IRN Report and the Historical 
IRN Report which reside in the TDMS 2 data base. Current and historical data, 
including latest ICD revision and IRN incorporation are available on-line in TDMS 2. 

The Space Shuttle Program shall utilize the payload Preliminary Interface Revision 
Notice (PIRN)/!RN Report which resides in the Automated Mission and Payload 
Tracking System (AMPTS) for current payload ICD information. 
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5.3 PROGRAM DOCUMENT DESCRIPTION AND STATUS REPORT 

The Space Shuttle Program shall utilize NSTS 08102, Program Document Description 
and Status Report, which is a listing of current revisions and changes to all SSP base¬ 
line documents. This report will be used to identify the status of the NASA baseline 
documentation. Applicable projects, design activities and contractors shall be furnished 
NSTS 08102 to review and, if necessary, to redline changes to the document. NSTS 
08102 shall be maintained by the Space Shuttle Management Integration Office. 

5.4 CONFIGURATION STATUS REPORTING 

Configuration accounting and verification functions shall maintain or have access to 
complete and accurate records on the location and configuration status of all Contractor 
Furnished Equipment (CFE), GFE, and commonality items of equipment. The records 
will include such data as nomenclature, manufacturer's identification, required and 
scheduled delivery dates for modification kits, planned and actual usage of each serial 
number, and additional notes as required. 

Records will be monitored by each project on the status of changes being managed by 
the project. These records will enable an audit trail to be accomplished, from accep¬ 
tance of each CR through verification of change implementation. The records will 
include a cross-reference to the following, where required: 

a. CRs 

b. Change proposals 

c. NASA Configuration Control Board Directives (CCBDs) 

d. Baseline documentation status 

e. ICD status 

f. Technical directives 

g. Contract Change Authorization (CCA) (if applicable) 

h. Retrofit/Modification kits 

Status accounting reports will be used to support acceptance and delivery of hardware/ 
software as well as reviews and inspections. 

The foregoing elements of data (as a minimum) shall be maintained by the design activity/ 
contractor and shall be a product of the configuration accounting system. Appropriate 
summaries, evaluations, and status reports will be prepared from this data for submittal 
to the NASA as required. 
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5.5 MISSION EQUIPMENT CONFIGURATION ACCOUNTING 

Mission equipment installation requirements for each Space Shuttle flight are specified 
in the MECSLSI drawing and the CCCD for that flight. The configuration accounting 
system which shall be used to track mission equipment assets, status compliance with 
the MECSLSI and CCCD drawing requirements and provide associated reports is 
defined in Appendix R. 

5.6 MISSION-ESSENTIAL SOFTWARE DATA RETENTION 

Mission-essential software elements (GPC, SSME, LPS and Mission Control Center 
[MCC]) shall retain “as flown" software configurations (executable code, mission-unique 
data, and related documentation) for a minimum of three years. Refer to NSTS 07700, 
Volume XVIII, Book 3, Computer Systems and Software Requirements, Software Man¬ 
agement and Control, for further details. 
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6.0 CONFIGURATION VERIFICATION 

Configuration management includes activities associated with assuring that require¬ 
ments are properly implemented and hardware/software is certified as having been 
designed and built to the correct configuration. This effort shall be an intrinsic part of 
the overall management approach on the program. 

6.1 SSP REQUIREMENTS VERIFICATION 

The Space Shuttle Program, having authority for the development and control of the 
NASA baseline, shall ensure that all external agency requirements and interfacing 
requirements between program elements/projects have been properly incorporated into 
the baseline. Requirements, design, and hardware/software configuration reviews will 
be conducted as necessary to ensure that this is accomplished. These reviews also will 
be used to establish baselines for further development of requirements and to validate 
the approaches taken to the solution to these requirements. The reviews considered to 
be SSP requirements are defined in the following subparagraphs. 

6.1.1 Program Requirements Review (PRR) 

This review encompasses all major SSP participants and is chaired by the Director, 
Space Shuttle Operations, or delegated representative. The purpose of the review is to 
review and update program requirements and evaluate the management techniques, 
procedures, agreements, etc., to be utilized by all participants. This review evaluates 
CM procedures and formats required to satisfy the program requirements. 

6.1.2 Shuttle System Requirements Review (SRR) 

This review encompasses all major SSP participants and is chaired by the Director, 
Space Shuttle Operations, or delegated representative. The purpose of this review is to 
update the program and system requirements to be utilized by the contractors for the 
SSP. These requirements are documented as the NASA SSP baseline (reference 
Paragraph 3.1.4), implemented with the contractors, and placed under configuration 
change control. 

In addition to the system requirements, other program element requirements may be 
reviewed and evaluated to ensure they conform to the system requirements and that 
contractors have correctly interpreted the NASA requirements for the program ele¬ 
ments. 

Prior to or at the SRR, ICD responsibilities will be defined and documented and master 
schedules for ICD completion will be established. 

6.1.3 Preliminary Design Reviews (PDRs) 

Preliminary Design Reviews will be conducted by each responsible NASA Project office 
with their NASA in-house design activity/contractor, prior to, or very early in the detail 
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design phase. The PDR is a technical review of the basic design approach for configu¬ 
ration items and for selected major changes to these items to assure compatibility with 
the SSP and Project requirements (including interface requirements) and the produci- 
bility of the design approach. Cost and schedule relationships also will be reviewed. 
This review will update the Project requirements to be utilized by the NASA in-house 
design activities/contractors for the applicable Project. These requirements, including 
those contained in the Statement of Work/Requirements, shall be documented as the 
NASA Project baseline, implemented with the NASA in-house design activity/con¬ 
tractor, and placed under configuration change control. In the event Project 
requirements have been baselined prior to PDR, they will be updated as required to 
incorporate the applicable results of the PDR. 

All ICDs applicable to a PDR should be baselined to reflect appropriate interface 
requirements prior to PDR completion. When any PDR is completed, all applicable 
ICDs must be baselined and implemented with the affected contractors and placed 
under configuration change control. 

Typically, the items for review at the PDR should include the following: 

a. Preliminary ICDs 

b. Design analyses 

c. Layout, general arrangement, and envelope drawings 

d. Schematics and block diagrams 

e. Sizing, trade study, and design study results 

f. Material and process specification listings 

g. Applicable procurement specifications 

h. Test requirements 

i. Mockups and models 

j. Updated plans, procedures, and schedules 

k. Commonality candidates; identification, rationale, and status 

l. Proposed additions to the NASA baseline 

m. Selected SR&QA documentation (FMEAs, CILs, hazard analyses, etc.) 

The PDR should result in the authorization to the contractor to proceed with further 
design in accordance with the reviewed design approach, interface requirements, com¬ 
monality items, etc., and approval or update of the project baseline documentation. 
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SUMMARY 


A comprehensive software control and system configuration management process 
for flight-critical digital control systems of advanced aircraft has been developed 
and refined to ensure efficient flight system development and safe flight operations 
Because of the highly complex interactions among the hardware, software, and system 
elements of state-of-the-art digital flight control system designs, a systems-wide 
approach to configuration control and management has been used. Specific procedures 
are implemented to govern discrepancy reporting and reconciliation, software and 
hardware change control, system verification and validation testing, and formal doc¬ 
umentation requirements. An active and knowledgeable configuration control board 
reviews and approves all flight system configuration modifications and revalida¬ 
tion tests. This report includes examples of configuration management forms and a 
description of the tracking process which ensures accurate and consistent records. 
This flexible process has proved effective during the development and flight test¬ 
ing of several research aircraft and remotely piloted research vehicles with digital 
flight control systems that ranged from relatively simple to highly complex, inte¬ 
grated mechanizations. 


INTRODUCTION 


The complex and integrated nature of the flight-critical digital control sys¬ 
tems of advanced aircraft necessitates a rigorous software control and system con¬ 
figuration management process to ensure efficient flight system development and safe 
flight operations. Over the past 10 years, the Dryden Flight Research Facility of 
NASA Ames Research Center has developed and refined a comprehensive configuration 
management process, which has been applied to several research aircraft and remotely 
piloted research vehicles with digital flight control systems that ranged from rela¬ 
tively simple to complex and highly integrated mechanizations. This flexible proc¬ 
ess has proved effective for the F-8 digital fly-by-wire (DFBW) and the highly inte¬ 
grated advanced fighter technology integration (AFTI) F—16 research aircraft, as 
well as the 3/8-scale F-15 spin research vehicle (SRV), the highly maneuverable air¬ 
craft technology (HiMAT), and the drones for aerostructural testing (DAST) remotely 
piloted research vehicles. 

Various methods and approaches for software control and system configuration 
management have been used successfully, and many have been published in the lit¬ 
erature. All systems have some unique and dominant characteristics; advanced air¬ 
craft flight control systems are no exception. Because of the highly complex inter¬ 
actions among the hardware, software, and system elements of a state-of-the-art dig¬ 
ital flight control system design, a systems-wide configuration control and manage¬ 
ment process is necessary. Experience with the development of various advanced 
flight systems has shown that use of separate hardware and software configuration 
control procedures is ineffective for highly integrated flight systems in that many 
of the difficult design, development, and testing issues involve interactions bet¬ 
ween hardware and software systems. 

This paper describes the process and procedures of a highly successful and effi¬ 
cient software control and system configuration management technique for advanced 
aircraft digital flight control systems. Experience with several advanced vehicle 
systems is described, and specific examples are given to illustrate the implemen¬ 
tation process. 



NOMENCLATURE 


AFTI 

CCR 

DAST 

DFBW 

DR 

HiMAT 

PC 

RAV 

SRV 

STR 

WO 


advanced fighter technology integration 
configuration change request 
drones for aerostructural testing 
digital fly-by-wire 
discrepancy report 

highly maneuverable aircraft technology 

program change 

remotely augmented vehicle 

spin research vehicle 

system test report 

work order 


SYSTEM DEVELOPMENT PHASES 


The proper application of a successful software control and system configuration 
management process requires a thorough understanding of the various phases required 
for development of an advanced system. The primary phases for development of an 
integrated digital flight control system for an advanced aircraft are definition of 
requirements, design, production, and ground and flight test (fig. 1). Recognizing 
that all these phases are likely to require interactive development over the life¬ 
span of a complex system is critical in the implementation of a configuration manage¬ 
ment process. 

The definition of requirements typically begins with specification of the broad 
mission requirements and culminates with a conceptual design of the system. The con¬ 
ceptual design is presented in a comprehensive system specification document which 
describes the overall system characteristics, including the functional requirements 
of the hardware and software. Other requirements defined in this phase include the 
equipment and facilities required for system testing, the staffing plan, and the doc¬ 
umentation procedures. 

The generation of detailed specification documents outlining specific system 
hardware and software requirements is an initial step of the design phase. These 
documents must satisfy the requirements of the comprehensive system specification 
document. During the design phase, the overall plan for software control and system 
configuration management is defined, and specific procedures and responsibilities 
are established. A series of specification and design reviews is essential for the 
efficient evolution of the system development. 
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After the critical design review is the software and hardware production phase, 
which requires the mechanization of various tools and facilities. Generally, the 
hardware and software elements of a complex system are initially tested indepen¬ 
dently using specialized stand-alone equipment and facilities. After functional ver¬ 
ification tests, the software and hardware elements are integrated for final ground 
testing, overall system validation, and flight qualification tests. A flight readi¬ 
ness review is conducted prior to flight test evaluations to assess the results of 
the various ground tests and the flight readiness of the vehicle and flight systems. 

To properly manage these phases of development, an overall software control and 
system configuration management process is needed to provide consistent treatment of 
software and hardware elements. This process is designed to include both the soft¬ 
ware and hardware elements of advanced integrated systems and accommodates the inher 
ent iterative nature of advanced digital flight control system development. The con 
cept of a systems-wide approach to configuration control and management (which means 
that the same process is used for both software and hardware system elements) is a 
primary contributor to the successful application of this process on a number of 
highly complex aircraft systems. 


PROCESS DESCRIPTION 


The primary purpose of the software control and system configuration management 
process for flight-critical digital flight control systems is to provide a method 
for efficient flight system development and a procedure for assuring safe flight 
operations. The process is designed to control system configuration changes by man¬ 
aging the primary system development phases described previously, and to resolve dis¬ 
crepancies uncovered during system testing. In addition, the configuration control 
process prescribes stringent test and documentation requirements and provides for 
visibility of changes across all involved engineering disciplines through formal 
review procedures. 

The overall software control and systems configuration management process 
(fig. 2) can be divided into four phases, analogous to those of the system develop¬ 
ment process. Requirements for configuration changes arise from new software or 
hardware system requirements or from discrepancies noted during system analysis or 
test. An important element of this change-in-requirements phase is the documenting 
and reporting of system discrepancies. All system development personnel are respon¬ 
sible for documenting and reporting all discrepancies, software or otherwise, found 
during system operation and test. A standardized form for discrepancy reporting 
aids the documentation and tracking process. When the discrepancy is discovered, 
the anomalous behavior and the system software and hardware test configuration are 
documented in detail. The cause of the discrepancy and the required fix are usually 
determined at a later time; a method of working around the problem or a temporary 
fix may be incorporated if necessary to continue testing. 

After the change requirements are defined, analyses are undertaken to define and 
then design the required software or hardware modifications. For changes required 
as a result of a system discrepancy, the cause and required fix are indicated on the 
discrepancy report form. A configuration change request form is prepared for any 
change required. Before being implemented, each system hardware or software change 
must be reviewed and approved by the configuration control board which includes soft 
ware, hardware, systems, operations, and management personnel. This board provides 
the forum for disciplinary and flight test engineers to discuss the changes and 
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their impacts/ identify test or retest requirements, and determine the effects of 
the changes on operational procedures or system performance. The configuration con¬ 
trol board approves, returns for further analysis, or rejects the specific hardware 
and software changes requested and then formally documents the action taken. If a 
system hardware modification is required, a work order form is prepared to provide a 
detailed description of the modification. If a system software modification is 
required, a program change notice is prepared to describe the specific change and 
the reason for and impact of the change. 

The primary function of the software control and system configuration management 
process during the production phase is to assure that proper procedures are followed 
in the implementation of the approved changes and that requirements for updated doc¬ 
umentation are met. A hardware drawing is updated, and after fabrication, the modi¬ 
fication is inspected for quality assurance and compliance with the work order. The 
software manufacturing process is highly dependent on the specific computer equip¬ 
ment and software development tools and varies greatly from system to system. An 
important element common to all software production processes is the requirement for 
adherence to formal written procedures detailing specific sequences in the manufac¬ 
turing process as well as for updating the formal software documentation. 

The configuration management process has an integral function in the testing 
that follows the incorporation of any change. Procedures that govern verification 
and validation test requirements are implemented for both software and hardware mod¬ 
ifications. Written system verification and validation test reports are required 
for all system elements and for all system changes. The verification test for a 
hardware change includes the visual inspection and continuity check which determines 
that a hardware item is constructed and wired in accordance with the drawing. Hard¬ 
ware validation involves a series of systems functional tests which are performed to 
qualify the design and its implementation. Software verification is the testing 
process that formally assures that the software is coded in accordance with its 
design specification. The software validation step assures that the specified soft¬ 
ware change accomplishes the desired objective within acceptable limits and operates 
correctly in the operating environment of the total system. The system validation 
testing often uncovers system discrepancies resulting from the integration of the 
hardware and software. Adherence to an established written policy concerning soft¬ 
ware reverification and system revalidation testing after a software change is 
required. The documented test results are reviewed by the configuration control 
board for adequacy and completeness before the modified hardware or software is 
released for pre-flight checks and flight testing of the system. 

The configuration control board plays a vital role in a successful software con¬ 
trol and system configuration management process. The board assures that a coordi¬ 
nated closed-loop process exists at all system development stages by controlling sys 
tern configuration changes arising from new requirements or discrepancy reconcilia¬ 
tions and by reviewing implementation details and test results. An active and knowl 
edgeable configuration control board greatly enhances the efficiency of complex and 
integrated system developments by maintaining the essential common thread of knowl¬ 
edge and experience. 


Documentation 

An essential part of the software control and system configuration management 
process is a comprehensive and consistent method for documenting developmental 
changes. The primary goal of this documentation is to provide communication and 
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therefore visibility of changes across all involved engineering disciplines. The 
documentation generated during the validation and test phases of the system develop¬ 
ment process provides the means by which conformance to the overall mission require¬ 
ments is tracked and controlled. The material generated for the various design and 
readiness reviews is also a valuable documentation element. 

A method for "checks and balances" is provided on the forms used for system con¬ 
figuration control documentation arid tracking (fig. 3)• Closing the loop on the 
change control process is essential in the development of a complex flight system. 

To assure that changes are tracked, tested, and documented properly, the discrepancy 
report, configuration change request, program change, work order, and system test 
report forms are cross-referenced. Each form has a unique identification number to 
aid this cross-referencing process. Examples of the forms used are included in the 
appendix. 

The closing action section on the discrepancy report form provides space for 
recording the configuration change request, program change, and work order numbers 
identifying the implemented change. The configuration change request form cross- 
references all the other forms and is the primary form used for assuring that the 
change has been implemented and documented properly. The program change form used 
for software changes references the discrepancy report and configuration change 
request numbers. In addition, specific software release identification and docu¬ 
mentation updates are referenced on this form. The work order form includes a ref¬ 
erence to the discrepancy report if the change is the result of a system discrepancy 
and also provides for documentation of the quality assurance inspection. Hardware 
drawing updates are generally attached to the work order form. The system test 
report forms are used for documenting all formal system testing and the retesting 
required after system changes. For tests resulting from the implementation of sys¬ 
tem changes, the program change or work order number is referenced. 


Status and Tracking 

An advanced flight system development program commonly has a large number of dis¬ 
crepancies, changes, and tests in various stages of resolution, design or analysis, 
and accomplishment, respectively. An efficient method of tracking progress and gen¬ 
erating status information is required for overall project management and scheduling 
purposes. Manual recordkeeping and documentation control may be adequate for sim¬ 
pler system development projects, but becomes cumbersome and ineffective on larger, 
more complex projects. 

An automated method for maintaining tracking and status information for complex 
flight system configuration modifications has been developed using a microprocessor- 
based computer system. Standard data-base management software is used to create 
files containing all pertinent information required to track system configuration 
status. The computer system is used to store, update, and retrieve information per¬ 
taining to the status of discrepancy reports, configuration change requests, program 
changes, work orders, and system verification/validation test reports. Hardware 
and software documentation updates are also tracked. Various sorting and indexing 
methods are used to generate hard-copy status reports in a variety of formats. This 
automated system has proved to be an accurate and efficient tool in the overall soft¬ 
ware control and system configuration management process. 
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APPLICATION EXPERIENCE 


The process for software control and system configuration management has been 
applied to several research aircraft and remotely piloted research vehicle programs, 
including the F-8 DFBW, AFTI/F-16, HiMAT, F-15 SRV, and DAST. All these vehicles 
have integrated digital flight control systems; the mechanization complexity varies 
greatly. The key elements of the process were adapted for specific application on 
each of these programs, demonstrating the flexibility of the overall concept. The 
point at which the formal configuration control process begins varies from program 
to program but generally starts when the baseline system configuration has matured 
to the point of allowing effici^ht formal testing without undue restrictions or 
operational difficulties. The software control and system configuration management 
methods described in the previous section represent the current status of a continu¬ 
ally evolving process; experiences from each program contribute refinements and 
enhance both the overall approach and specific procedures. The process, as detailed 
in figure 2, is certainly not envisioned to be directly applicable for all programs; 
however, it has provided a basic framework from which useful configuration control 
and management procedures have been developed. 

The configuration control process.used on the highly complex AFTI/F-16 air¬ 
craft was largely based on these concepts. Over 100 flights were accomplished and 
13 major software releases were developed and qualified for the AFTI/F-16 digital 
flight control systems during the first year of flight testing. More than 330 dis¬ 
crepancy reports were processed during the development and flight test activity, and 
over 95 software program changes were implemented. Specific details of the config¬ 
uration control process used on the AFTI/F-16 aircraft program are contained in 
reference 1. The following sections outline application experience on the F-8 DFBW 
and HiMAT research programs; the experiences with the F-15 SRV and DAST programs 
were similar. 


F-8 DFBW Program 

The F-8 DFBW research aircraft was first flown in 1972 with a simplex, full- 
authority digital flight control system using ultrareliable system hardware from the 
Apollo spacecraft program and a triply-redundant analog backup system. The first 
flight of the second phase of the F-8 DFBW program, which occurred in 1976, used a 
triply redundant, full-authority digital flight control system for primary control 
and a triplex analog backup system. The flight qualification and validation exper¬ 
ience gained on the F-8 DFBW flight program is described in reference 2. The com¬ 
mitment to remove the aircraft’s mechanical control system before the initial flight 
test forced the development of a comprehensive set of qualification procedures, 
including a process for software control and system configuration management. This 
early process, which stressed rigorous testing procedures and formal documentation, 
provided the basis for the current process. 

The triply redundant primary flight control system of the F-8 DFBW was designed 
as a flexible research testbed, and has allowed many flight control and system 
research experiments to be investigated in flight. In over 6 years of active flight 
testing and nearly 150 flights, a total of 40 software releases have been qualified 
and used in ground and flight tests. ’The software control and system configuration 
management system has been used successfully to track over 500 discrepancy reports 
and to process more than 320 program changes to the onboard flight-critical software 
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The F-8 DFBW aircraft also has the capability to use a remotely augmented 
vehicle (RAV) flight test technique for investigating advanced control law con¬ 
cepts in a cost-effective manner. The RAV concept (ref. 3) uses a ground-based, 
FORTRAN-Drogrammable digital computer for control law computations and up and down 
telemetry links to allow complete closed-loop control. The technique was designed 
to provide the flexibility and versatility necessary to investigate advanced or 
highly speculative control concepts in flight. The onboard flight software treats 
the simplex RAV interface and mechanization as another flight control mode and con 
tains the necessary validity checks required to maintain overall system integrity. 

The RAV ground computer system and software configurations were developed and 
managed using the same process as was used for the onboard software and flight sys¬ 
tems. The system testing approach was modified slightly to account for the less 
critical nature of the RAV ground systems and software. The systems-wide approach 
to software control and systems configuration management made the accommodation of 
the additional RAV software and system hardware elements a relatively easy task. 

The process thus demonstrated its inherent flexibility to accommodate and manage 
complex system hardware and software elements that might be added to an advanced 
aircraft flight system after the initial development phase. 


HiMAT Program 

The HiMAT program was conceived to demonstrate advanced technology concepts 
through flight tests of scaled aircraft using a remote piloting technique. Advanced 
composite structures, aeroelastic tailoring, a digital integrated propulsion control 
system, reduced static stability, and a microprocessor-based digital fly-by-wire con¬ 
trol system are all elements of the HiMAT program. Closed-loop primary flight con¬ 
trol is performed from a ground-based cockpit, using a digital computer and up and 
down telemetry links. A backup flight control system for emergency operation resides 
in an onboard computer. The onboard systems, which are designed to provide fail¬ 
safe or better capabilities, use two microcomputers, dual uplink receiver/decoders, 
and redundant hydraulic actuation and power systems. 

The HiMAT system development and flight qualification was a complex, highly 
integrated task (ref. 4). Four independent flight-control digital computers, all 
with different software programs, were required to meet the research program objec¬ 
tives. The two ground-based computers were programmed in FORTRAN, and the two 
onboard computers were programmed in assembly language. The software development 
facilities, verification tools, and ground support equipment used for system valida¬ 
tion testing were specific to each computer system. The various computer hardware 
and software elements were quite diverse, yet the overall flight system functions 
were highly integrated. A coordinated and consistent software and system develop¬ 
ment process was essential in the qualification and flight test activities. 

In over 4 years of development and ground and flight test activities, 30 soft¬ 
ware releases were generated for the 2 onboard computers, 24 software releases for 
the primary ground computer, and 11 software releases for the other ground computer. 
Nearly 500 discrepancy reports were written and resolved, over 320 work orders were 
processed for flight system hardware modifications, and over 480 program changes 
were incorporated in the various software elements. In general, the HiMAT program 
used the outlined discrepancy reporting, software change, and system verification/ 
validation test procedures quite rigorously. However, the system hardware modifica¬ 
tion process was tailored to respond to the many unique and dynamic requirements of 
the HiMAT flight system development. In particular, many of the system hardware 
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changes did not require the review and approval of the configuration control board; 
the cognizant systems engineer authorized the modifications directly. Any major 
flight control system hardware modifications and those of an integrated-systems 
nature were processed according to the established procedures for overall system 
configuration management. As an illustration of the iterative nature of an advanced 
system development project, the system development history of the HiMAT program is 
summarized in figure 4. 

The software control and system configuration management process proved to be an 
effective and efficient method to track, document, and manage this advanced aircraft 
system development activity. The capability of this process to accurately and effi¬ 
ciently manage the development of a highly integrated flight system containing multi¬ 
ple, diverse subsystems with an overall systems-wide approach was again demonstrated. 

CONCLUDING REMARKS 


An effective software control and system configuration management process for 
flight-critical digital control systems of advanced aircraft has been described 
and illustrated. The process has been successfully applied to a number of programs 
involving research aircraft and remotely piloted research vehicles with advanced 
flight control systems. Key factors to be considered in the development of a soft¬ 
ware control and system configuration management process that works include: 

1. The highly complex interactions among the hardware, software, and system 
elements of a state-of-the-art digital flight control system design require that a 
systems-wide approach be used for configuration control and management. 

2. Application experience has shown that maintenance of separate hardware and 
software configuration control procedures is ineffective for highly integrated 
flight systems in that many of the difficult design, development, and testing issues 
involve interactions between hardware and software systems. 

3. The implementation of a configuration management process must account for 
the fact that all the primary system development phases are likely to require itera¬ 
tive development over the lifespan of a complex flight system. 

The primary purpose of the software control and system configuration management 
process for flight-critical digital control systems is to provide a method for effi¬ 
cient system development and a process for assuring safe flight operations. The 
principal elements of the process include: (1) procedures for reporting, tracking, 
and reconciling all system hardware and software discrepancies? (2) a structured 
process for identifying, reviewing, and implementing system hardware and software 
configuration changes? (3) rigorous system verification and validation test proce¬ 
dures? (4) accurate and consistent documentation requirements? and (5) an active and 
knowledgeable configuration control board to review and approve all system configu¬ 
ration modifications. 

The effectiveness and flexibility of this software control and system configura¬ 
tion management process has been demonstrated in use on several advanced flight sys¬ 
tem development programs of varying complexity and diverse configurations. 
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APPENDIX - CONFIGURATION MANAGEMENT FORMS 


This appendix includes examples of typical forms used in the systems configura 
tion management documentation and tracking process: Discrepancy Report, Configura 
tion Change Request, Work Order, Program Change, and System Test Report. 




DISCREPANCY REPORT (DR) 

-REPORT GROUNO - BASED OR AIRBORNE PROBLEM 
WITH HARDWARE, SOFTWARE, OR ASSOCIATED OPERATION. 

-SEE PROCESS SPECIFICATION 00-7 FOR DETAILS 


PART A — AIRCRAFT/FACILITY PORTION OF OR 




(91 DISCREPANCY - Lai ALL tr^t*** 


FAILURE 1ST SUSPECT 


(14) F1X0IN6S Of 0E7AJLE0 FAILURE AMALTS1S - Cju***: 


1(101 MO/OY/YR Jm|ftr/OPH« I ( 12 ) FW STATUS I (1J| SISM7U«/MG/SITt 


i 1151 MQ/QT/YR I (16) fLT/Of MAS I (17) FH STATUS I (it) SlGNATURE/ORG/SITE 



FAILURE CAUSE FOUMO - OMMi Utlad ANm 


(19) CORRECTIVE A CLOSING ACTIONS: 


I (701 PCN'S. CCR S WO S. »tt. 1(211 M0/8T/TR • (22) FU/Of MRS * (73) FW STATUS l (24) SIGNATURE/13R8/SITE 


AC FT/FACILITY CLOSEOUT ACTION COMPLETE 


I (231 ACn/FACIUTV CLOSEOUT SIGNATURE: 


(2«j ACFT/FACIUTY CLOSEOUT SIGNATURE 


PART B - □ SUB-ASSY PORTION OF OR. USE FOR HARDWARE OR SOFTWARE. USE 1 PART B FOR EACH MAJOR OR LOWER ASSY 


(33) 01SCREPANCT - Lai ALL prrrwAf 
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BLOCK II CONTINUED DEVELOPMENT (CONTINUED) 


7.5 INITIAL OPERATIONAL TEST AND EVALUATION (IOT&E) (OPTION) . The 
contractor shall fabricate and deliver four Block II missiles that 
replicate the production configuration of the missile. The contractor 
shall provide field team support to process missiles for.flight. The 
contractor shall also provide support of flight test activity at WSMR 
Control Center and at the launch site. The Government will establish and 
publish restrictions related to the contractor’s test support. The 
contractor's support shall conform to all of these restrictions. The 
contractor shall also respect and abide by directions and decisions of the 
operational test conductor. When requested, the contractor shall employ 
diagnostic failure analysis and reporting techniques for analyzing and 
reporting hardware and software failures encountered during the IQT&E. 

7.6 RANGE SAFETY. The contractor shall support preparation of 
National Range Documentation, and comply with WSMR Range Safety and missile 
flight test planning requirements. Missile flight test planning shall 
include support for preparation of Range Safety Data to meet WSMR 
requirements. Missile destruct procedures, reaction times, and debris 
footprints shall be developed. 

7.7 SURFACE DANGER AREA. Prior to test firings (including sled 
testing), an interim surface danger area, defined to a one-in-one million 
escapement probability criteria, shall be constructed utilizing Army TACMS 
Block I methodology. Both normal and malfunctioning modes, assumptions 
made, and a description of the system behavior for each malfunction 
possible and probability of occurrence shall be included. The final 
surface danger area assessment shall be derived from the data used for the 
interim footprint, flight data, and data derived from simulations and 
flight characteristics with the integration of the BAT submunition. The 
final surface danger area shall also include a one-in-one-hundred-thousand 
escapement probability footprint. The interim and final surface danger 
areas shall be included as an appendix to the SAR. 

8.0 CONFIGURATION MANAGEMENT. 

8.1 FUNCTIONAL BASELINE (FBL) . The FBL for the Army 

TACMS Block II continued development shall be the Army TACMS system 
specification, MIS-38578 Addendum II. 

8.2 REQUESTS FOR OFFICIAL MILITARY NOMENCLATURE. The contractor shall 
prepare and submit to the procuring activity requests for nomenclature for 
major end items and their principle components which are to be type 
classified. 

8.3 CHANGES TO GOVERNMENT CONTROLLED DOCUMENTATION. Changes to 
documentation under Government control shall be incorporated only after 
Government approval of Engineering Change Proposals (ECPs). The contractor 
shall assign ECP numbers obtained from the Government. Notices of Revision 
(NORs) shall be prepared for each affected drawing or specification and 
shall be included as an integral part of the ECP. 

8.4 METRICS. All data and documents developed under this SOW shall 
utilize metric units. 

8.5 DOCUMENTATION STORAGE AND CONTROL. The contractor shall have 
custodianship of all technical documentation generated and/or maintained 
under this SOW and shall utilize a central fireproof repository appropriate 
for accommodating all original and master documentation and computer tapes 
or other media. The contractor shall establish and maintain control access 
to these data LAW the documentation storage and control portion of the CMP. 
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BLOCK II CONTINUED DEVELOPMENT (CONTINUED) 

a 6 DELIVERY OF DRAWINGS. (Jnclassified/unlimited rights data to be 

submitted to the Government repository shall be in raster image format(on 
maenetic -*oe f9-track 1600/6250 bits per inch [3PI] fully compatible with 
M?C0M DIGITAL STORAGE AND RETRIEVAL ENGINEERING DATA SYSTEM (DSREDS], 
compression is Comite’ Consultatif International de Telegraphique et 
Teleohoricue (English: International Consultative Committee on Telegraphy 
and Telepnonv] [CCITT], group-4, non-wrap format, document identifier 
record is specified in the attachment to Document Summary List [DSL], 
document tvoe codes same as for aperture cards ) or microfilm aperture 
format (compatible with and IAW DESREDS requirements from document 
originals, as sets in numerical sequence). Classified/limited rights data 
shall be delivered in microfilm aperture card format only. Each shall be 
marked appropriately to identify the data contained within. 

9.0 PRODUCT ASSURANCE. 

9.1 MAJOR NON-CONFORMANCES. All critical and major non-conformances 
shall be processed through formal materiel review board procedures. The 
procuring^activity reserves the right of approval for material review board 
determinations related to critical and major non-conformances. 

9.2 PROHIBITED PARTS, MATERTELS, AND PROCESSES (PMPs). A listing of 
prohibited PMPs is found at attachment 07. 

9.3 HARDWARE/SOFTWARE VALIDATION. All special inspection equipment 

(SIE) and special test equipment (STE) and their associated software shall 
be validated by the procuring activity prior to use for acceptance of 
hardware. 

10.0 INTEGRATED LOGISTICS SUPPORT (ILS). 

10.1 PROGRAM REQUIREMENTS. 

a. The contractor shall implement the Integrated Support Approach 
that is a part of this contract. The contractor shall conduct a logistics 
demonstration. 

b. The Government shall periodically review and/or audit 
contractor adherence to integrated logistics support processes established 
by the contractor for the performance of the Block II program. Depending 
on the results of these reviews, the Government may issue recommendations 
for process improvement (CIOs) or provide NODs. The contractor shal 
responsible for developing and implementing corrective action plans to 
return contractor processes to control. 

10.2 SYSTEM SUPPORT PACKAGE (SSP) FOR DEMONSTRATIONS AND TESTING. The 
contractor shall assemble and deliver all items/equipment identified on the 
SSPCL and deliver to the test sites 30 days prior to the scheduled start 
date of each test. 

10.3 LOGISTICS SUPPORT ANALYSIS\LOGISTICS SUPPORT ANALYSIS RECORD 

(LSA/LSAR). The contractor shall perform LSA during the _. _ . 

integration of the BAT submunition. The LSA performed on Army TACMS Block 
II shall be consistent with the existing Army TACMS Block LA program. LSA 
shall also be performed on modifications to the M270 launcher and MLRS 
training and support equipment to support Block II application, and sha 

be consistent with existing M270 launcher data base. 

10.4 BLOCK II DOCUMENTATION/STORAGE/ACCESS REQUIREMENTS. 
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SPACE SHUTTLE ONBOARD SOFTWARE 
PROGRAM MANAGEMENT 

AND 

CONFIGURATION CONTROL 

PROCESS 



1. SPACE SHUTTLE ORBITER AVIONICS SOFTWARE 


1.1 INTRODUCTION 

The purpose of the Space Shuttle Orbiter Avionics software is to provide the means of bringing the essential 
but diverse portions of the Orbiter together into a system which responds to the demands of its users. The 
software development process is managed to ensure that the delivered product provides the required func¬ 
tions and sendees and is only changed under controlled conditions. This plan provides an overview of the 
software development process and the management approach which the IBM Corporation uses to assure 
that quality software products are provided to NASA according to schedule. 

1.1.1 Purpose 

This document provides IBM's management approach for the development of the Space Shuttle Orbiter 
Avionics software to support the Operational Flight phase. The software development process as described 
in this document includes software maintenance. .Ail processes are identical for development and mainte¬ 
nance except for authorizing document and approval processes. 

1.1.2 Scope 

This process is applicable to the development, verification, and certification of the Onboard Space Shuttle 
Orbiter Avionics software. 


1.2 RESPONSIBILITIES 

The development and maintenance of the Space Shuttle Orbiter Avionics software is the responsibility of 
IBM in response to NASA supplied requirements. For functional capability development, IBM responds to 
software Change Requests (CRs) approved by the Shuttle Avionics Software Control Board (SASCB) of the 
NASA Project Office (PO). IBM also has the responsibility for the development and maintenance of Flight 
Software Application Tools (FSWAT). FSWAT is the set of softw'are tools that supports the development 
and reconfiguration of the Flight Software. Changes to the FSWAT are. governed by Support Software 
Change Requests (SSCRs) and Support Software Discrepancy Reports (SSDRs). Both FSW and FSWAT 
changes are packaged into Operational Increments (OIs) and implemented and tested by IBM in the Soft¬ 
ware Development Facility (SDF). It is the responsibility of IBM to completely test each of these incre¬ 
ments in preparation for subsequent reconfiguration prior to being used to support STS flights. Formal 
review and acceptance of the implementation and testing of each 01 is the responsibility of the NASA 
Spacecraft Software Division (SSD). IBM participates in the configuration inspection (Cl) chaired by 
NASA/SSD. Cl is held for each OI following completion of the independent verification phase of the devel¬ 
opment 

For flight to flight reconfigurations, IBM is responsible for the certification of the PASS FSW. IBM inde¬ 
pendently produces a reference Mass Memory and compares the final products as well as some intermediate 
products, to Space Transportation System Operations Contract's (STSOC's) Mass Memory. Miscompares 
are analyzed and corrected as required. Furthermore, formal testing is performed on the flight Mass Memory 
to verify the flight readiness before IBM signs the Flight Readiness Statement. 

Certification is only applicable to PASS Reconfiguration builds of deliverable products specified by the Mass 
Memory' Integration Plan (MIP) as delimited by the FRONTROOM BACKROOM INTERFACE 
CONTROL DOCUMENT (ICD). 
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1.3 PROJECT MANAGEMENT 


1.3.1 Project Manager 

The project manager is responsible for ensuring that the software being designed, developed and tested for 
the Space Shuttle Orbitcr Avionics meets the requirements and objectives established by VASA. The 
project manager also ensures adherence to processes, procedures, and configuration management. Full com¬ 
pliance with these items is indicated with the project manager's signing of the Certification of Flight Read¬ 
iness (COFR) for each shuttle mission. To achieve these objectives the project manager has organized a 
project-oriented organization (see Figure 1-1 on page 1-3). This organization ensures that management has 
access to and control of all resources necessary to meet schedules and performance objectives. The Software 
Quality Assurance (SQA) organization is independent of the OBS project and management. 

1.3.2 Onboard Space Shuttle 

The project manager is responsible for the development of all Primary' Avionics Software System (PASS) 
capabilities, certification of all flight systems, and the development of application support software systems 
used in the preparation of the flight systems. The maintenance of project baselines and schedules is accom¬ 
plished through a project-wide Backroom Baseline Control Board (BBCB). The chair person of the BBCB 
is a staff function reporting directly to the Project Coordination Manager. Members include second level 
management and key staff personnel from all appropriate areas. The charter of the BBCB is threefold: 

• Define, negotiate and baseline project-wide development, build, test and delivery' schedules 

• Control and baseline flight software change baselines (Change Requests and Discrepancy Reports) 

• Coordinate interproject technical issues 

The organizational structure involves six major areas. The areas correspond to the following general activ¬ 
ities and are described in detail in the following paragraphs: 

• Development and maintenance of new and existing flight software capabilities 

• Verification of flight software capabilities 

• Flight operations support 

• Flight reconfiguration certification 

• Development and test of support software systems 

• System build 

1.3.2.1 Avionics Software Development 

The Avionics Software Development organization is responsible for the development of enhancements and 
maintenance to flight software applications and operating system capabilities. These software enhancements 
are defined by the NASA PO Shuttle Avionics Software Control Board (SASCB) via CRs. In collaboration 
with NASA PO and SSD, these changes are packaged into software systems called OIs and nominally devel¬ 
oped on six month centers. In general, a single 01 will support multiple STS flights with software releases 
called OF's. 

In addition to development, the organization is also responsible for software system architecture and memory 
analysis. 
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Figure 1-1. Onboard Space Shuttle Project Organization 


1. SPACE SHUTTLE ORBITER AVIONICS SOFTWARE 
















1.3.2.2 Avionics Software Engineering and Verification 

The verification organization is responsible for the test of enhancements to the flight software and operating 
system. Each OI is tested and made available for reconfiguration, i.e., the application of mission and 
payload specific data. 

The Engineering organization is responsible for reviewing all proposed requirements changes to the flight 
software to ensure that the software can perform properly (Central Processing Unit (CPU) timing measure¬ 
ments, etc.), and meet desired flight objectives. 

1.3.2.3 Test and Operations 

The Test and Operations (T&O) organization supports installation and maintenance of delivered systems in 
the users sites which include, the orbiter vehicle and test facilities at the Kennedy Space Center (KSC), the 
Shuttle Mission Simulator in Houston, the Shuttle Avionics Integration Laboratory’ in Houston, the KSC 
Automated Test Set, the Cargo Integration and Test Equipment at KSC, the JSC Avionics Engineering Lab¬ 
oratory (JAEL), and other sites as required. 

1.3.2.4 Flight Software Application Tools (FSWAT) 

The Flight Software Application Tools organization is responsible for building software used for the develop¬ 
ment, reconfiguration, and test of PASS Flight Software. The types of software produced include: flight 
simulation, preprocessors, post-processors, build and data analysis tools. FSWAT is also responsible for 
maintaining the software configuration management data bases. The major functions performed by FSWAT 
include: writing requirements, generating design and code, performing unit test and verification, and gener¬ 
ating and publishing User's Guides and requirements documents for the produced software. 

1.3.2.5 System Build 

The System Build organization is responsible for building FSW and FSWAT systems from source. It also 
performs all the flight-to-flight Reconfiguration Certification builds. This group assures that all developed 
software changes are put on systems in a controlled fashion. Other functions performed by this group 
include building integrated Mass Memories and generating software deliverables. 

1.3.2.6 Contracts 

The contracts department is primarily responsible for cost manpower monitoring, analysis and reporting. In 
addition, the department is also responsible for subcontract monitoring and GFE and IBM property admin¬ 
istration and control. 

1.3.2.7 Flight Certification 

The Certification task is performed in parallel with but not in line to the STSOC reconfiguration process. 
IBM independently builds a Mass Memory. This Mass Memory is compared with the one built by STSOC 
and the results are reported to SSD. The STSOC Mass Memory- is then copied over the IBM build Mass 
Memory so that independent testing can be performed on the Flight Mass Memory. Results of this testing 
is reported to SSD through a formal Certification Test Review (CTR). IBM signs the Flight Readiness 
Statement to denote that the PASS FSW is certified. 
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1.3.3 Software Quality Assurance (SQA) 

The independent SQA organization has the responsibility for assuring that all software development phases 
of the contract are conducted in accordance with the requirements and standards specified in the contract 
and any applicable IBM imposed requirements. The SQA personnel are responsible for assunng the fol¬ 
lowing: 

1. Preparation of Software Quality Assurance Plans (SQAP) 

2. Direction of program quality assurance efforts 

3. Coordination with DCASPRO, customer and subcontractor representatives on quality matters 

4. Auditing the accomplishment of the SQAP requirements. 


1.4 MANAGEMENT CONTROLS 


To insure management control of flight and support software development and certification activities the 
Onboard Space Shuttle project utilizes the following mechanisms: 

• A series of internal IBM control boards with direct interfaces to corresponding NASA control boards 
(see Figure 1-2 on page 1-6) 

• A rigorously controlled Configuration Management Data Base (CMDB) containing release contents 
(Requirements changes, discrepancy corrections) under the control of the IBM board chairmen (see 
Figure 1-3 on page 1-7) 

• A series of weekly and bi-monthly status and policy meeting with various levels of IBM and 
NASA/Spacecraft Software Division management 

• Weekly and bi-monthly publication of baselines, project and detailed schedules and development plans 
including the IBM internal BBCB datapack which provides a comprehensive project summary'. 
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Figure 1-2. IBM Control Boards 
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6. CONFIGURATION MANAGEMENT 


Configuration management is the process of authorizing and documenting every modification to each 
product end item. This is accomplished through the use of two procedural concepts: configuration control 
and configuration management tools. 


6.1 CONFIGURATION CONTROL 


Configuration control is the establishment of technical control points called baselines and the systematic 
e\aluation, coordination, and disposition of all proposed changes to these baselines. The management of 
configuration control within IBM is the primary' responsibility of the Backroom Baseline Control Board 
(BBCB) to coordinate the overall project configuration elements so that each activity element is efficiently 
integrated with the rest of the project. 

6.1.1 Project Configurations 

The BBl,B com cnes regularly v\ith management and key staff personnel from all appropriate areas to 
compare actual status and scheduled milestones. The following baselines are reviewed and revised or re¬ 
scheduled as necessary by the BBCB in order to support both the other project activities and product com¬ 
mitments: 

a. Active flight software systems available 

b. Active simulator systems available 

c. Flight software build and release schedules 

d. Flight software build and release contents 

e. Simulator software build and release schedules 

f. Simulator software build and release contents 

g. Certification build and compare schedules 

h. Support hardware configurations 

i. Computer time schedules 

j. Configuration management data base (CMDB) contents 

k. Receipt dates for government and STSOC furnished input data items 
k Commitments to the customer (NASA) 

I he flight software and the Flight Software Application Tools (FSWAT) configuration control is delegated 
to four sub-boards which report to the BBCB. Those boards are: the Primary Avionics Software System 
(PASS) Discrepancy Report (DR) Review Board, the Requirements Review Board (RRB) which maintains 
requirements Change Request (CR) configuration control for the PASS, the Support Software Review- 
Board (SSRB) which maintains CR configuration control for FSWAT, and the Support Software DR Board 
(SSDRB). 

6.1.2 Flight Software 

The PASS DR Board is charged with the responsibility of reviewing and reporting on the results of each 
suspected flight software error identified. Recommendations are made to NASA as to the resolution of each 
such problem. NASA is then responsible tor approving or disapproving the recommended action for each 
discrepancy. In cases where changes in PASS requirements are involved, the RRB is the reviewing and 
reporting board. Modifications to the CR baseline are determined by the NASA control board approvals of 
the new requirements. Maintenance of the PASS CR baseline within IBM is the responsibility of the RRB. 
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6.1.3 Flight Software Application Tools (FSWAT) 


The Support Software Requirements Control Board (SSRBj within the FSWAT organization is responsible 
for FSWAT requirements and maintenance. These responsibilities are described in Sections 3.2.2 and 3.6. 
respectively. 


6.2 CONFIGURATION CONTROL DOCUMENTS 

Changes to the PASS or FSWAT software are documented as either DRs or CRs. CRs are initiated when a 
program requirement has changed. A DR is initiated when known or suspected errors are detected in the 
software requirements, design, or code. DRs and CRs may be originated by NASA, IBM, or any using 
agency of IBM end items. 

Fach DR or CR is logged into the C\IDB and forwarded to the line organizations of software development 
and software verification for assessment. Their assessment is reviewed by the appropriate CR or DR review 
board where basic recommendations of disposition and implementation are made. The review board deter¬ 
mines the recommendation to be presented to NASA. The final approval is received via the NASA control 
boards. Subsequent handling of the report or change is done by the line organizations to perform modifica¬ 
tions in the software as required after which the DR or CR is closed. The status of the report or request 
during the cycle is maintained in the CMDB. 

6.2.1 Change Requests 

A CR is initiated when a change to a baseline requirement is proposed or a discrepancy other than an imple¬ 
mentation error has occurred. Requests may be originated by NASA, Rockwell, IBM, or other contractors. 
Information about the change includes a description, justification, computer program end item baseline 
impacted and affected software areas. Agencies external to IBM originating CRs submit them to NASA. 
IBM originated CRs go to the RRB and then to NASA Spacecraft Software Division (SSD). The change is 
assigned a control number by NASA. 

Once an IBM originated CR has received RRB approval it goes to the SSD Change Control Board (CCB) 
with other non-IBM generated CRs. A CCB approved CR must then be approved by the SASCB before 
IBM is directed to implement it. At that time the CR is scheduled in the CMDB and baselined for a spe¬ 
cific software release system. The CMDB then senes as the baseline for each software system. Updates to 
the software can only be performed for approved change authorities as designated in the CMDB. 

The CMDB is the baseline against which independent verification builds their test plans. All change author¬ 
ities are specifically verified. 

6.2.2 Discrepancy Reports 

Any user at any test facility or operational site in which the PASS software or the FSWAT software is in use 
may originate a DR to identify a known or suspected software error. 

Information about the error is recorded by the originator and includes identification of the suspected module 
and the system being used, conditions at time of error, and a specific description of the error. Any agency 
which uncovers an error supplies the information about the error on a DR form with a unique control 
number which identifies the discrepancy in subsequent activity. IBM sends a copy of the discrepancy to 
NASA for review and enters it into the CMDB. An analysis sheet containing a full discussion of the anal¬ 
ysis and the effects of the problem is added to the DR once resolved. IBM maintains these documents for 
future reference. Once IBM and NASA agree that a DR should be resolved via a software change, that 
change is scheduled in the CMDB for an appropriate release. The CMDB then senes as the baseline for 
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each software system. Lpdates to the software can only be performed for approved change authorities as 
designated in the CMDB. 

The CMDB is the baseline against which independent verification builds then test plans. All chance author- 
itics are specifically verified. 


6.3 CONFIGURATION MANAGEMENT TOOLS 


6.3.1 Configuration Management Data Base (CMDB) 

The CMDB is the repository- for the control and descriptive information relating to project CRs or DRs. 
Ihc designation "change request" includes any and all control instruments (e.g., CRs, SSCRs) authorizing 
changes to project requirements or baseline items. DRs authorize changes when project software systems or 
procedures do not conform to requirements. The CMDB provides the mechanism for management, 
tracking, and control of flight software, support software, and test software in both the Shuttle Software 
development and production environment. Build programs which create or modify permanent (baseline) 
segments in system data bases (e.g., Development System Base (DSB) and mission data base) do so under 
the authority of approved CRs and DRs as found in the CMDB. The CMDB is maintained by the config¬ 
uration management and control functions as the centralized storage facility for all relevant change control 
data. It sen es as the source of status query responses and status report generation. In addition, it maintains 
a limited cumulative change history of other system data bases. 

6.3.2 Member Name Implementation Data Base (MNIDB) 

I he Implementation Data Base (IDB) represents a central repository for storing FSW and FSWAT support 
software data related to an associated DSB or Mission System Base (MSB), the KEPT library, or a mission 
data base (MDB). An IDB associated with a DSB or MSB contains manually supplied PASS and FSWAT 
information referred to as descriptive data. This data represents information supplied by designers, devel¬ 
opers, and verifiers and contains information such as program ownership and processing instructions, per¬ 
formance criteria, and or hidden cross references in the software. Both DSB MSB and IDBs contain FWS 
and its support software descriptor data for all combinations of features that they are required to support. 
An IDB associated with an MDB initially contains only the descriptor data for that subset of MSB IDB 
names required in support of the mission being built. This includes all member names unaffected by features 
as well as those member names affected by the selected feature set associated with the mission. Subsequent 
data is added to an IDB in an MDB as a result of mission reconfiguration activities when, for example, load 
module and MMU addresses are installed following linkage editor and MMU build activities, or when 
‘ Lo , ad values installed for specific FSW variables following execution of the I-Load Preprocessor. 
KEPT IDBs contain, instead of normal baseline segments, pool elements that have previously been build 
into one or more MDBs or System Bases and are awaiting future use in additional MDBs or SBs. 

An IDB is organized to provide a set of information related to a basic unit of FSW and or support software 
data identifiable by its member name. 

The data related to member names are stored in a member name implementation data base (MNIDB). The 

MNIDB contains descriptor data for member names that are such things as programs, procedures and 
macros. 
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6.3.3 Build Control List Data Base 


The Build Control List (BCL) data base is used during all system builds (DSB, MDB) as a depository for 
build progress status data as well as to control the sequencing and activities performed in builds. The BCL 
data base provides for individual BCLs (one per build) to be created, managed, used, and removed as the 
build is planned, performed, and reported to the CMDB. Each BCL in the BCL data base is separated from 
other BCLs both physically and logically so that builds do not interfere with each other. As a part of build 
preparation for a system, a BCL header segment is created in the BCL data base by the BCL manager trans¬ 
action. It is under this header segment that the system's BCL will exist when its build occurs. 


6. CONFIGURATION MANAGEMENT 6-4 





APPENDIX H 


LIST OF INTERVIEWEES 

Col. David Mathews, U.S. Army (Retired), Senior Guest 
Lecturer, Systems Management Department, Naval Postgraduate 
School, Monterey, California 

Professor Norman Schneidewind, Information Systems Engineering 
and Management Group, Systems Management Department, Naval 
Postgraduate School, Monterey, California 

Professor Carl R. Jones, Information Systems Engineering and 
Management Group, Systems Management Department, Naval 
Postgraduate School, Monterey, California 

Mr. William Miller, U.S. Army Tactical Air Missile System 
(ATACMS), Configuration Manager, ATACMS Project Office, SFAE- 
MSL-AB (South Site/Building 7571), Redstone Arsenal, Alabama 
35898-5650 

Mr. David C. Schultz, Manager, Management Integration 
Office/GM, Mail Code MA7, National Aeronautics and Space 
Administration, Lyndon B. Johnson Space Center, Houston, Texas 
77058 

Mr. William Pruett, Manager, Shuttle Software Development 
Group, Lyndon B. Johnson Space Center, 2101 NASA Road 1, 
Houston, Texas 77058-3696 

Mr. Ted Keller, Manager, Space Shuttle Project Coordination, 
Loral Space Information Systems, 3700 Bay Area Boulevard, 



Suite 600, Post Office Box 58487, Houston, Texas 77258 

Mr. Ted Pearson, Department Head, Competency 3.0, Naval Air 
Warfare Center Training Systems Division, 12350 Research 
Parkway, Orlando, Florida 32826-3224 

Cdr. Thomas Crosby, Deputy Department Head, Competency 3.0.A, 
Naval Air Warfare Center Training Systems Division, 12350 
Research Parkway, Orlando, Florida 32826-3224 


168 



LIST OF REFERENCES 


1. Secretary of Defense Memorandum. Specifications and 
Standards - A New Wav of Doing Business . July 20, 1994. 

2. Test and Evaluation Management Guide . Defense Systems 
Management College Press, Fort Belvoir, Virginia, August 
1993. 

3 . Humphry, W . S . Characterizing the Software Process: _A 

Maturity Framework . Technical Report, Carnegie Mellon 
University/Software Engineering Institute, Pittsburgh, 
1987 . 

4. Reifer, Donald J. Software Management . Fourth Edition, 
IEEE Computer Society Press, Los Alamitos, California, 
1993. 

5. Cleland, David I., Gallagher, James M., and Whitehead, 
Ronald S. Military Project Management Handbook , McGraw- 
Hill, Incorporated, 1993. 

6. Department of Defense Directive 4245.7-M. Transition 
from Development to Production , 1985. 

7. NAVAIR Instruction 4130.1C. Naval Air Systems Command 
Configuration Management Policy . January 31, 1992. 

8. Department of Defense Instruction 5000.2. Defense 
Acquisition Program Procedures . February 23, 1991. 

9. Military Standard 973. Configuration Management , April 
22, 1991. 

10. Department of Defense Standard 2167A. Defense Systems 
Software Development . U.S. Government Printing Office, 
February 29, 1988. 

11. Military Handbook 61. Configuration Management , Joint 
Logistics Commanders, May 13, 1991. 

12. International Electrical and Electronics Engineering 

Standard 828-1983. IEEE Standard for Software 

Configuration Management Plans , June 24, 1983. 

13. Eggerman, W.V. Configuration Management Handbook , TAB 
Professional and Reference Books, Blue Ridge Summit, PA, 
1990 . 

14. Naval Training Systems Center Instruction 4130.3. Naval 
Training Systems Center Configuration Management Policy 


169 



and Responsibilities , September 29, 1993. 

15 ■ Commercial Practices for Defense Acquisit 
Defense Systems Management College Press, 
VA, January 1992. 


ion Guidebook . 
Fort Belvoir, 


170 


BIBLIOGRAPHY 


Beard, Robert L. III. Development of an Automated CM System 
for the Stock Point Logistics Communications Environment 
(SPLICE) Project Management Staff . Naval Postgraduate 
School, Master's Thesis, B293. 

Berlack, H. Ronald. Software Configuration Management , New 
York, Wiley, 1992. 

Buckley, Fletcher J. Configuration Management: Hardware, 

Software, and Firmware . New York, Institute of Electrical 
and Electronic Engineers, 1993. 

Cleland, David I., Gallagher, James M., and Whitehead, Ronald 
S. Military Project Management Handbook . McGraw-Hill, 
Incorporated, 1993. 

Commercial Practices for Defense Acquisition Guidebook . 
Defense Systems Management College Press, Fort Belvoir, 
Virginia, January 1992. 

Department of Defense Directive 4245.7-M. Transition from 
Development to Production . 1985. 

Department of Defense Instruction 5000.1. Defense 

Acquisition . February 23, 1991. 

Department of Defense Instruction 5000.2. Defense Acquisition 
Program Procedures . February 23, 1991. 

Department of Defense Instruction 5200.1R. Information 
Security Program Regulation , June 1986. 

Department of Defense Instruction 0-5205-7. Special Access 
Program (SAP) Policy . January 4, 1989. 

Department of Defense Instruction 5134.1. Under Secretary of 
Defense (Acquisition), U.S. Government Printing Office, 
August 8, 1989. 

Department of Defense Instruction 7750.5. Management and 
Control of Information Requirements , U.S. Government 
Printing Office, August 7, 1986. 

Department of Defense Standard 2167A. Defense Systems 
Software Development . U.S. Government Printing Office, 


February 29, 1988 



Dickinson, David G. Implementation of a Configuration and 
Management System for LANs . Monterey, California, Naval 
Postgraduate School, Springfield, Virginia. Available 
from the National Technical Information Service, Master's 
Thesis D5633, 1992. 

Eggerman, W.V. Configuration Management Handbook . 1st 
Edition, Blue Ridge Summit, Pennsylvania, Tab Books, 
1990. 

Genet, Richard Paul. The Development of a Configuration 
Management Approach for the Operational Phase of NATO 
Seasparrow Project , Naval Postgraduate School, Research 
Paper, G2596. 

Humphry, W. S. Characterizing the Software Process: A 

Maturity Framework , Technical Report, Carnegie Mellon 
University/Software Engineering Institute, Pittsburgh, 
1987. 

International Electrical and Electronics Engineering (IEEE) 
Standard 828-1983. IEEE Standard for Software 

Configuration Management Plans . June 24, 1983. 

Military Handbook-61. Configuration Management , Joint 

Logistics Commanders, May 13, 1991. 

Military Standard 973. Configuration Management . U.S. 
Government Printing Office, April 22, 1991. 

Mission Critical Computer Resources Management Guide . Defense 
Systems Management College. 

NAVAIR Instruction 4130.1C. Naval Air Systems Command 
Configuration Management Policy . January 31, 1992. 

Naval Training Systems Center Instruction 4130.3. Naval 
Training Systems Center Configuration Management Policy 

and Responsibilities . September 29, 1993. " 

Office of Management and Budget Circular A-109. Major System 
Acquisitions . U.S. Government Printing Office, April 5, 
1976 . 

Reifer, Donald J. Software Management . Fourth Edition, IEEE 
Computer Society Press, Los Alamitos, California, 1993. 

Roum, Christopher John. A Study of the DoD Configuration 
Management Policies and Procedures as Applied to the F/A- 


172 



18 Strike/Fighter Program . Naval Postgraduate School, 
Master's Thesis, R7855. 

Secretary of Defense Memorandum. Specifications and Standards 
- A New Wav of Doing Business . July 20, 1994 

Snyder, Marlene A. An Analysis of Naval Aviation 

Configuration Status Accounting , Naval Postgraduate 
School, Master's Thesis, S66323. 

Systems Engineering Management Guide . Defense Systems 
Management College, U.S. Government Printing Office, 
January 1990. 

Test and Evaluation Management Guide . Defense Systems 
Management College Press, Fort Belvoir, Virginia, August 
1993 


173 




174 





INITIAL DISTRIBUTION LIST 

No. of Copies 

, 

1. 

Defense Technical Information Center. 

Cameron Station 

Alexandria, Virginia 22304-6145 

.2 

2. 

Library, Code 52 . 

Naval Postgraduate School 

Monterey, California 93943-5101 

.2 

3. 

Defense Logistic Studies Information Exchange . 

U.S. Army Logistic Management College 

Fort Lee, Virginia 23801-6043 

.1 

, 

4. 

David V. Lamm, Code SM/Lt . 

Naval Postgraduate School 

Monterey, California 93943-5101 

.4 

5. 

W.M. Woods, Code OR/Wo . 

Naval Postgraduate School 

Monterey, California 93943-5101 

.1 

6. 

Michael Sovereign, Code CC/Fo . 

Naval Postgraduate School 

Monterey, California 93943-5101 

.1 

7. 

LTC John T. Dillard, Code SM/Dj . 

Naval Postgraduate School 

Monterey, California 93943-5101 

.1 

8. 

CDR Tom Crosby, Code 3.0.A 

Naval Air Warfare Center Training Systems Division . 

12350 Research Parkway 

Orlando, Florida 32826-3224 

.1 

9. 

Ray Hammond, Code 3.5.1 

Naval Air Warfare Center Training Systems Division . 

12350 Research Parkway 

Orlando, Florida 32826-3224 

.2 


175 














